Coordination as a Key to Success

Generally I’m a big believer in delegation. I choose to delegate task along with ability to make decisions about the subject and responsibility for achieving success or failing. I accept the fact it brings failures sometimes which I’m partly responsible for. However it gives people a right to decide (which they usually consider as something positive) and teach them accountability (which is always positive). It also eliminates makes organization healthier as management tasks are distributed all over the team and the boss is no longer a bottleneck. Several failures are really a fair price to get all of that.

Having said that, there are moments where you have to switch to manual steering. Your PM is on the road going on weekly meeting with customer and you have emergency situation in that very project. Customer escalated an issue which looks stupid but is really (I mean really) important for them. You’re running out of time in the project while the team looks like children in the fog trying really hard but with no visible effect. At the moment no one is able to take a look from higher perspective being highly dedicated on own tasks, yet unfortunately leaving people’s efforts disconnected. I could continue until this blog post is the longest one in the Internet. Then, it is time to forget about your automatic transmission and switch to manual shift. Someone has to take the role of coordinator.

No, it is not micromanagement. You don’t tell people how to do things. You just coordinate everyone efforts. In the real life it usually ends up running from one desk to another in amok having multiple phone calls every time you move between different rooms in the office. First phase is learning – where are problems, how they can be fixed, who can do that. Then it’s time to check why it isn’t going the right way automatically. Maybe someone isn’t aware of importance of task. Maybe you lack a person, who is on holidays. Maybe information flow sucks. And finally it’s your time. Time to act. Time to go and kick asses. To get the job done. You go explain people why their part is essential, help them with whatever they need to do what they need to do and finally you go check another bottleneck which appears on the way.

Yes, I know, being COO the whole thing is easier because actually most people I talk with are my subordinates, so sometimes they find a bit discomforting when rejecting me when I ask them to do something (but only sometimes and only a bit). Anyway, usually the issue is not in lack of will to do some action, but in lack of awareness that it is darn important and should be done right now. I mean now. Another typical case is several packet lost in communication between people which ends up with people solving the wrong problem or waiting for thing which will never come. It doesn’t require a hero to solve those issues. A couple of phone calls and another couple of chats is usually enough to congratulate yourself a job well done. Of course as far as you work with people you can count on (and fortunately I do).

Every single time when it happens to me to run as mad through the office trying to push things a bit further, ensuring myself everyone’s effort is focused on achieving the same goal I feel that’s the real work. Not those long strategy meeting, not discussing with customers functional details of the new project, not all those bureaucracy which follows you since you were promoted to middle management roles, but seeing things being created in minutes with a little bit of your help. Don’t get me wrong, all those others things are (I guess) important, but won’t replace me that feeling of being still useful from time to time.

Leaving my satisfaction on a side I saw way too many situations where team ended up hitting hard to the wall with their heads just because no one was able to coordinate and guide people a bit. It’s like binder between bricks. As far as you don’t use it you end up with a pile of bricks instead of house. A regular project management is like binder while building a house, but an emergency coordination role is a bit like borrowing a bag of cement from adjoining building site when you run out of yours. Without that bag you will probably end up with a pile of bricks (maybe more impressive but still) no matter how hard you try.

Prestige of Quality Assurance

The other day I’ve heard that old rusty idea:

“We should hire a bunch of youngsters as testers. If they’ll appear worthy and will be smart maybe (but just maybe) they should be offered a development job.”

No, no, no. Not that way. Quite the opposite. If a developer shows his worth, maybe he should be offered a quality assurance job.

1. From the best quality engineers I know, almost all have programming background. Even when they do some black-box tests they understand how software is constructed which makes their job much more conscious.

2. Testing is still very often considered as clueless clicking on the application waiting for the crash. The whole set of quite interesting tasks in the area of quality assurance is somehow forgotten. Load tests, performance tuning, tracking down architectural limiters in application growth etc. All of them more interesting than adding yet another edit window in yet another database application.

3. A number of boring tasks ascribed sometimes to testers are rather developers’ duties. I’ve heard: “Maybe testers would develop some unit tests for us.” What? Who? That’s developer’s job, isn’t it?

Yes, I know I’m dreaming. Unfortunately quality assurance roles are considered as worse ones. People understand promotion as moving from quality assurance position to development, (almost) never the other way. No one think for a longer while about details, the whole thing usually ends up after comparison of prestige brought by both positions.

I will still start discussion whenever someone will come with any idea considering testers as a worse kind. I think there’s a bit of truth in saying that developers treat themselves as sacred cows too often, but to be honest one of main sources of having the situation alike are managers who don’t appreciate testing roles, considering them as low-budget options.

As far as decision-makers attitude won’t change there won’t be much difference in that area.

Blogger Localization Rules

OK, I ranted over Google Blogger. OK, twice. I’m sorry. I won’t do it any more. Sorry. But please, don’t make all that localization case worse every single time you can. OK, you guys can think that switching label from “software design” to


is a great idea, but I think it is not. You know I don’t actually know what the heck does means.

What more, you don’t really understand it in your engine. I have typed s-o-f-t-w-a-r-e design, but you’ve shown it as design on the blog.


Maybe you aren't aware but there's a difference. Make up your mind, please. If you change it, at least interpret correctly what you've changed. Oh, I have better idea. Don’t screw it. Leave it alone. It would be better that way.

Blogger Localization Counter Strikes

To add another two cents to my recent rant on Blogger localization issues: other day Blogger localized (Polish) website greeted me with a message.


The message used to be written in Polish. I don’t know why it is now in English. An error? Anyway, if you care to localize the whole website why don’t you care to translate the message which is shown on landing page (for users who are automatically logged in)? I know guys from Google cared to translate the message to Polish but somehow it went back to its original English version and from user perspective there’s no difference between both situations.

I think I’ll just switch the language to English.

By the way I think I’m happy I haven’t gone to Finland with Blogger language not set. Language setting would look like that:


Good luck in finding it. I don’t even try to think what would it be with Japanese or Chinese.

Definition of Success

When I was thinking about software success stories to add my piece to recent meme one particular project came to my mind. Actually it had nothing to do with my influence on its result so it didn’t suit to the meme, but still I thought I’d share it. I consider the project as a success although it’s rather far from a classic example of well-crafted piece of software driven by a committed team of seasoned professionals. It was a bug tracking application which my very first employer had developed for their own projects.

Several information about Track, which was the name for the application (very creative name, indeed), shows it was far, far away from perfection when it comes to judging project/product management and software development processes.

1. Track was both proprietary and legacy project almost from its birth. Language it was written in (Clarion – yes, I know you consider it more as car audio manufacturer than programming language) fits well to the picture.

2. The application was treated as a putrid egg among developers. It wasn’t a core task for anyone. It was always a sure-shot candidate to pass to a newbie developer joining the team. Youngsters didn’t know what a nugget was handed to them.

3. As the result, developers working on Track changed several times which ended up with no particular style of coding. What more, at least a couple of them were learning the technology while developing the application. A great idea to create an example how the code shouldn’t look like.

4. No one really could remind the real testing period for Track. Developer’s tests were enough. Testing is overrated anyway.

5. Flexibility and Track doesn’t rhyme well. Actually it doesn’t rhyme at all. The number of things which were hard-coded and assumptions made during development was really impressive, although I’m not sure if that’s something to be proud of. It’s hard to imagine any other company which Track would show usefulness for.

OK, great start of the story of success, isn’t it? The story lying behind Track’s birth was simple – company bought quite expensive bug-tracking solution which unfortunately didn’t appear as useful as it had been expected. As company was paying the rent developing software they decided to write something similar but with needed improvements added. The rest is pretty well described above, yet every issue or decision can be quite well-grounded.

1. Track was proprietary but no one ever wanted to sell it to anyone. OK, one of our parachute-CEOs had the idea for a moment, but fortunately the application was just un-sellable. It was legacy but actually that wasn’t any issue here as no one ever wanted to sell it to anyone. OK, one of our parachute-CEOs had the idea for the moment, but fortunately the application was just un-sellable. The programming language was than the most intensively used one in the team and no one ever wanted to sell the application to anyone...

2. Having newbies working on the project the chances were good they had some time to spend on their non-core tasks. With seasoned developers it wasn’t always so obvious. And despite their opinion about spaghetti code and strange ideas with implementation it was quite a good lesson for youngsters what they could meet in the wilderness out there.

3. As far as the application worked somehow (it could be magically even, no one would complain) it didn’t really matter what the quality of code was. The goal was to make things done, and they were done indeed. Why bother?

4. Track was used in production so we were testing it everyday. And there were two categories of bugs: those which annoyed you so much you were able to convince the developer to fix them or those which you got used to and live with them. The former, as the definition tells, were fixed. And somehow being a director of the team you could submit much more issue to the first category. Strange.

5. The application wasn’t flexible but it suited to the very company extremely well. It was like a glove crafted especially for you. When we wanted some functionality to be added it was added. When we wanted to do some usability improvements, nothing easier. Everything under control, here and now, just for a couple of hours of development and another couple listening to rants of lucky developer.

The whole project was actually nothing close to whatever you can read about either proper software development or proper project management. However year after year I appreciate Track more and more. I’ve worked with several different bug trackers and neither one was able to deliver user experience on the same level as the good old Track. It wasn’t by any means a great application, trying to migrate it to different environment would be like a wild-goose chase, but in that very company that very project was a success.

It’s the definition of success or failure which can change the project from one to another, so don’t be too fast calling the project either one.

Blogger Localization Issues

Some time ago Blogger was localized to Polish. Although English version was fine for me, nice thing to see the Polish market becomes important for Google. Unfortunately two things could be, let’s say, done better.

First, and much more important, is a decision when to switch the language. Actually as far as I can tell it is made basing on the IP address you connecting from. As every IP address (or rather a range of addresses) is geographically ascribed to specific country it (usually) can be resolved which language is spoken in the place you’re in. Unfortunately it doesn’t mean you speak that language.

When Blogger greeted me in Polish one day it was OK. I wasn’t really enthusiastic as Polish messages are longer (in number of letters) than English ones and I end up with content not fitting into the window.


I’m a lazy user so the effort to switch the language is way too much and I guess using the mouse scroll will allow me to burn a calorie or two so I left the Polish interface alone. Unfortunately I was on business trip in Austria and, what a surprise, Blogger greeted me in German. Then, it became an issue as my German is limited to “Bier”, “danke” and “noch einmal” or so. It’s like with the old trick with switching the language in someone’s Nokia to Finnish. Almost no one (except of Finns) could switch it back easily. Yes, I was puzzled. Switching the language just because my laptop has changed the gateway IP isn’t the great idea. I still have Polish locales in web browser and Google still knows I always change the Google search profile into the English one. There are at least a couple of better ways to resolve languages I understand.

Second thing is a small one. Not so long ago I saw a message:


As you can see I’m still too lazy to switch the interface language. Anyway, the message tells, as you can probably expect, “Downtime planned at 4PM PDT.” The message is in Polish but here in Poland we use different time formatting (would be 16:00 or 16) and what the heck is PDT? Yes, I know that’s Pacific Daylight Time and I’m able to check the difference between PDT and CET (Central European Time, which most of Poles actually know what the heck it is) is 8 hours. But when you bother to translate the whole site why not to remember about showing downtime messages using time zone which is familiar to me? Hey, you know which country I’m in, what vastly limits a range of interesting time zones.

Localization is never an easy thing. And it won’t be soon. It’s worth to think about scenarios users will follow first and then plan how the work should be done.

Talking with CFO

I came across a note about communication with CFO (found via PMThink) about project funding. My first reaction was: “Why the heck those two guys should actually organize a kind of semi-informal meeting just to exchange a couple of messages.” And can there really be a problem in that place?

After a second I corrected myself: “Remember, you work for a small organization, you don’t even have a formal role of either type out there.” We just leave politics outside and don’t even try (as far as I know) to play office wars. That’s cool about small organizations.

But yes, when I come back to times when I worked for Comarch, which is a company big enough to bring all inconveniences of being corporation but not yet mature enough to offer all of its bonuses too (although I’ve heard it’s improving a bit), it start to sound familiar to environment Naomi Grossman on bMighty presents. In that situation the advice is quite a reasonable one, although I wouldn’t bet it’ll work very often. When politics is involved and office wars are on everyday schedule you shouldn’t really expect much of one lunch with your enemy... I mean adversary. Go then and take your CFO for lunch (if you have any) as the investment isn’t a big one, but don’t expect much outcome.

And if you don’t have CFO, lucky you.

Software Product Success Stories

There’s a meme about successful projects initiated by Scott Sehlhorst. Generally the goal is to describe a project which, with your help, ended up as a successful one, especially considering what actually had made the project successful. I was recently pointed by Craig Brown to participate so here it is.

My choice is a worksheet application we use in our company. It’s a simple piece of software where all our technical staff fills which project they were working on during every month. Historically the application forced the user to enter data fine-grained data splitting the work effort done everyday to hours spent on different projects. The intention of the stakeholder was clear – get as much detail as possible to exactly count the project’s cost and profit. Of course to be exact users should fill data daily or every couple of days. They would spend a minute or two everyday on the task. The list of projects was of projects was automatically downloaded from CRM database, to make whole thing more convenient.

That was the theory. The practice was that every month, when reminder was sent by managers (with painful penalties for not filling the data included, which was quite a poor idea by the way), people were facing two options. They either spent whole day or so verifying what they were doing three or four weeks ago (which wasn’t very exact anyway) or they just entered whatever looked more or less reasonable hoping no one would find a fault with them.

That’s not all. Having a list of projects automatically downloaded from CRM database ended up with project list where you could find all the records of potential project we’ve never won (or even have been close to win) and virtually no one in technical department had even a sketch of idea what the heck was that. The list was long enough to create some issues when deciding which project people were actually working on. Several old names, a bunch of projects multiplied in several instances etc.

The situation was that users actually hated the application and it wasn’t bringing expected results anyway.

I did three things.

• I came with my opinion stated just above to decision makers (fortunately I was one of them) and convinced them the solution didn’t work at that moment so we could change it a bit with no pain whatsoever.

• I asked Gosia who was developing the application to make one change – switch from hours-per-day to days-per-month metric. User interface practically didn’t change and we didn’t care about integrity of database as we set up a new one. All changes took Gosia less than a day (or I just believe she is so fast) and I got a simple administering interface to fill official holidays as non-working days as a bonus. Then we officially switched “worksheet filling schedule” from daily to monthly regime, which actually was formalizing the reality but made the task less painful, as expected data was coarse-grained rather than fine-grained.

• The last thing was switching off automatic synchronization with CRM database and cutting off 95% of existing projects from worksheet database manually. That limited the list of projects to active ones only, hopefully improving user experience a bit more. Yes, now I have to add every new project manually into the database, but still that happens once per quarter and wasn’t so heartless to ask Gosia to add that feature as she had quite urgent work to do.

Where’s the success? Users hate the application less, which in this case is a success. We still have to send reminders to get the data filled, but that’s much less of a waste of time as people are forced to enter about 2-3 records on average choosing from 20 possible options instead of 50 out of hundreds of options and, magic happens, information isn’t less precise.

By the way making applications stink less should be in mission statements of many of software companies I know.

To invite a couple of people more to participate: Bruce Henry and Glen Alleman.

How to Make Use of Conferences

Nothing was happening here for more than a week as I was experiencing quite a painful mixture of scheduled business trips and flu. Now I’m using the weekend to reduce lag in my commitments and to repair health a bit before the next trip, which is planned on Monday.

One of events I attended recently was a multi-day conference organized by one of our main business partners. As you can expect being two days on the road and another couple sitting in the conference room you lose a direct link to information about what’s happening in your headquarters. Quick email checking during brakes and urgent phone calls are all you can get. You become less productive considering standard metrics.

However the last event was for me another proof you can easily exploit this kind of situations to get valuable results. Here’s why:

• New ideas. No matter how poor is the content, you can actually find at least a couple of new ideas when you look for them. If not directly from presenters than basing on your loose thoughts or on discussions with other attendants.

• Ad hoc discussions. Coming to the conference in a group (even a group of two) gives you a chance to discuss every out of the blue idea instantly. You will either find a supporter to your idea or an adversary who will force you to better reasoning.

• Time and atmosphere for serious discussions. During everyday work it’s always wrong time to switch off and talk about important things which unfortunately aren’t the most urgent ones usually. Being somewhere far away and time to spare during evenings (or while traveling) there’s actually good chance to have those important talks.

• Networking. That’s obvious but still usually undervalued one. Very often the most valuable outcome is brought not from planned presentations but from informal meetings with hosts and other attendees.

As far as you don’t go to the conference just to nap during presentations and drink a lot of beer in hotel bar during evenings it can be really valuable even when the set of presenters isn’t a very good one. It’s almost all in your hands.

Money as a Motivator

OK, the subject will be controversial. Money as a motivator. If you ask people what motivates them to work, they’d throw a bunch of different things much more often than they’d say about remuneration. Self-development options are evergreen here, but good atmosphere, top technologies, interesting products or well-organized processes are all mentioned more often than pure cash. By the way that’s one of my interview questions and, believe me, I hear “money” much, much less than I’d expect. Rob Walling presents quite a long list of different qualities which are valued more than money by developers. That’s first perspective.

Another one is pointing money actually does no good in the area of motivating people. David Carr in his post about money as a motivator shows a list of examples where money doesn’t really affect positively people’s work or even harm their attitude and, as a result, effectiveness. That’s other perspective.

Personally I strongly believe in non-monetary motivating techniques. “CEO’s handshake” followed by several words of praise can have much more impact than a payload of money. That’s another perspective.

Having said all of that, ask people if they’re willing to change the job for a better one in almost every aspect they can imagine. Better atmosphere, cooler technology, more interesting products and wide range of possibilities to self-develop. The only worse thing would be money. Few would follow. And if you leave aside those who are starting their own businesses you end up almost empty-handed.

Now, do another test – situation is the same but in the second job money is better, but e.g. atmosphere is worse. More candidates? What a surprise. Oh, is that really such a big surprise?

OK, where’s my point then? There are a few of them actually:

• Money alone doesn’t work very well when you want to add motivation over the standard effort.

• Money is very often used wrong. If it is so the result are usually opposite than intended.

• When used well, which is rather rare by the way, money can be a very good motivator.

• Non-monetary motivation techniques are essential but they don’t substitute remuneration – they supplement money.

• Money is more important for people than they’d be willing to admit.

• There are both managers who overestimate and underestimate the role of money as a motivator. There’s no rule here, although I think the former is more often.

Making Meetings More Effective

Some time ago I wrote about frequency of team meetings. That’s one thing to know how often you waste the time of the team but another thing is to limit negative impact meetings have on everyday work.

Rules to remember when you organize a meeting.

• Keep it fairly short. You waste not only your time, but all of people who are invited. 20 people on 1-hour meeting? It equals half of a workweek of one of your developers. No, throwing a joke or two isn’t banned but don’t let the meeting pupate into a party or a lunch break.

• Information flow is the king. There’s only one reason to make meeting – exchanging information. Information is the most valuable resource in any company. It must be. Other way, information flow would just work and we wouldn’t be surprised every day: “Have we just promised that thing to the customer? How come? Anyone wanted to tell me that?” When you run a meeting and waste time of several people make sure everyone who can be interested is invited. When information concerns whole team, everyone is invited. When it is a project status meeting, take all people who are involved. When you’re going to play office wars, keep it exclusive for board of directors.

• Be on time. Maybe it is a surprise but being a manger you shouldn’t be 5 minute late. That’s not in good form. If you expect others to be on time, keep the rule yourself too. When you’re on time you can expect everyone else will follow. And they will as soon as they see you care to give an example.

• Know when to stop the conversation. It just happens – people start talking about technology and they suddenly discuss their holidays or new secretary’s haircut, or go down do deep details where heads of most of attendees just blow off. Someone should have stopped that a couple of minutes before. Someone should have been aware the meeting has been going in that direction. Is that possible you are that someone?

• Know when to end the meeting. If you were on meetings when either the silence rules the room when no one else has anything more to add or on those where people all over the place start chatting about different things rather loosely connected with the subject you know someone wasn’t able to end the meeting when it was time. And it really has nothing to do with meeting room reservation time. Meetings, you know, they sometimes die before they were planned to do so.

• Reserve resources. Oh, when we’re on the meeting rooms... Very often reserving the room for needed time isn’t so easy, but cutting agenda by a half just because there was only half-hour slot in the room schedule doesn’t really help with running the whole thing smoothly. Sometimes you just have to make some concessions for, well, things like rooms.