|
Army v. Business
After reading through quite a lot of the material Joel posted on his site and a few of the conversations that take place here, I came to realize that although the problems discussed fit most businesses, they don't quite apply to my organization. I am a team leader of 12 programmers that are divided into 3 teams, and the organization around us is, well, big. This cumbersome organization I work for lacks basic flexibility and has a frustratingly complex and ineffective bureaucratic structure. But I'm not here to wine about my job. I'm here to actually ask for some advice.
There are a few things that are different at my workplace that set it aside from others:
1. I have no control over the hiring process. People just appear at the office doorstep, usually a long time after I requested for more personnel, and just enough time before I was expecting them, to catch me unprepared.
2. All new programmers receive a similar half-year training within the organization, which is, quite surprisingly, quite good. None of them have any degrees. They're about 19 years of age when they come, so they need a lot of tutoring and mentoring, even (or maybe especially) if they are the hyper-geeky-hackery type of people.
3. Programmers can't leave. Not on their own free will, and not on mine. I can't leave either, but that's another story. I can, if I really want to, have them transferred somewhere else, but that won't do me any good, because I won't get any more programmers or any less work to be done. So we're stuck with each other.
4. Programmers can't leave, and therefore keeping the morale up can be a tedious task sometimes.
5. Programmers leave on a pre-determined date, usually a few years (3 to 6) after starting to work on the project. So there are no real old-timers that know all the ins and outs of the system. Soon after getting that experience, they leave. Newcomers can't get the best training, because the best people to train them are also the best people to write code / design, and due to the relatively high rate or replacements, if all the old-timers do, is training newcomers, we won't be able to produce a single line of code.
6. Buying things, especially software, is such a lengthy process that I often find myself deciding in favor of writing code for something that I could buy just because 3 months of development using a 3-person team is twice as fast (and cheap, as time is my only resource) as going through that bureaucratic mess. Again.
7. There is no money issue. The organization doesn't earn money, it doesn't spend money. The project I'm working on has a budget, but I can’t spend it on anything useful, so – no money.
8. There is no money issue, so I have no influence on the programmers' salary and any economical incentive is out of the question.
If I didn't care, everything would be much simpler. But I do. I care, and although there is little to be gained if a project is successful (aside some respect from peers and managers), I try to manage it the best I can. And it's quite a challenge.
These are the main problems I'm facing. There are others, but traditional project-management techniques can be used to resolve them.
I've been a programmer on this team for 3 years, and then was promoted to the position of team leader. I've been doing this for half a year now. You could say I lack a great deal of experience. You would be right. That is exactly why I'm trying to read as much material on the subject as I can and discuss things with as many people as possible.
I won't go into describing the methods I try to make my team work and be productive. I want to hear your thoughts first. With some luck this will turn into a considerable discussion and all the gaps in my story will be filled over time.
Your thoughts on the subject are most welcome. Any thoughts. Just don't tell me to pack the picture of my dog into a nice brown carton box and leave (hell, I don't even have a dog). That's no way to resolve a problem. I really do think that frustration aside, what we have here is a management challenge. Which I want to tackle. With your help.
Gooli.
Eli Golovinsky
Monday, November 24, 2003
Has "the Russian front" lost its motivational value?
h
Monday, November 24, 2003
It's complicated to make programmers believe that a HR management software they are writing will help us win the next war.
Eli Golovinsky
Monday, November 24, 2003
Eli,
Interesting. Well social reward, in the deeply satisfying and not in the 'oh a card and balloon' sense, is my first response to how to handle this. You simply have to create an environment of camraderie. You are trying to gel the team, and that is about all you can do given your situation.
Read Peopleware. Its a good book that might help you out. Demarco and Lister are good guys, despite their fetish for office furniture. :)
Dustin Alexander
Monday, November 24, 2003
Its not about convincing them that the software that they are writing will help them win THE war. You have to convince them that it will help win THEIR war.
Break down the system into a tasks roadmap. Adjust it daily or weekly to show overall progress of all elements in the software and put it where the team can see it. Take a few breaks and get the guys together to chat about their lives, why they are into computers, etc. Have regular BS meetings, but also talk about the project. If you can get passionate about what you are doing, you will help them get passionate a lot easier. Come up with inside jokes, let the guys express themselves. The best you can do is create the kind of environment conducive to free thinking, donut munching research geeks. The rest is up to the team. Sadly, the type of environment you are in may be the exact opposite of that required to gel a good team.
Dustin Alexander
Monday, November 24, 2003
Eli, maybe you could have a talk with other units that have similar challenges, like the various logistics and support units. They often have very good programs for establishing the importance of the work that people do, and rewarding it and motivating staff.
Must be a Manager
Monday, November 24, 2003
Interesting advice from the "interview like a lawyer" guy ;-).
By the way, when is :-) making it into Websters?
Set up incremental goals, and reward them for reaching them. Turn good development into a game. Wasn't there a thread on paintballing and team building? Set up Doom (or whatever game is in vogue) tournaments after hours one day a week. Then take the lessons you learn from the game tournaments and apply them to work. Whichever team complete their tasks and with the fewest bugs takes the prize. Keep track on a score board the same way you would a tournament.
Cheesy? maybe, but friendly competition is probably better than the real adversarial relationships that can build up over time. It'll probably also break down the traditional roles and get ideas flowing more freely. Then it becomes about getting it done the best way possible rather than just getting it done.
If it doesn't work, you can try again in 3 years when you get a new batch of guys.
www.MarkTAW.com
Monday, November 24, 2003
The icnremental goals part, I think, is the most important. There is satisfaction in seeing you are getting a thing done, as opposed to feeling you are trying to roll a rock up a hill. You'd be surprised at how well people respond to the perception of progress, even without a related reward.
Dustin Alexander
Monday, November 24, 2003
And, Mark, if you look closely, I have added the smiley to the dictionary. Its just not in your edition yet. Its outdated. Time to buy a new 'Dustin' friendly one.
Interview like a lawyer, hmm. I'll probably be getting crap about that the rest of my life.
...
...
;-)
Dustin Alexander
Monday, November 24, 2003
Some ideas:
1. Write a small, simple document, stating the normal procedures, coding standards, etc... summarising the way things work in your team. That will help newcomers to fit quickly in the team. That will be helpful to capture the common knowledge of the older members of the team before they (and you) leave.
2. You sound very committed to your work, so I hope you can share your enthusiasm about the work you are doing. It always help to have an enthusiastic leader; I find it quite motivating.
3. Have clear milestones and celebrate when you achieve them. Just don't work for half a day and go for a meal together (or just give a free day period).
4. You can reward members of your team giving them either more responsabilities (and the opportunity to learn more/different things) or allocating them to more interesting parts of the projects you manage.
5. Rotate old timers on training. Each of them could spend half a day per week training newbies. In that way nobody feels that is just wasting time for very long periods.
6. Make clear to members of the team why they are sometimes reinventing the wheel: you can't afford to get software on time, but you are good enough to develop in house whatever you need. If they are young enough, they will feel proud of belonging to a resourceful team.
My $0.02.
uncronopio
Monday, November 24, 2003
Oh boy. If I remember correctly, the army is full of excellent tricks to motivate 18 year olds. Talk to one of the commanders of a basic training unit and you'll learn them all.
One easy method I can think of is the Tough Love method.
Spend a few weeks screaming at people. Nothing they can do is right. Make them stay in nights and weekends fixing little things.
After a couple of weeks, start dribbling out small amounts of barely noticible praise.
When I was at approximately week 3 of basic training, I would have done >anything< to get the drill sergeant to mutter "not completely terrible" under his breath. That was the closest thing to praise we had and we lived for it.
Joel Spolsky
Monday, November 24, 2003
Now that you mention it, that DOES sound a lot like the military... no control over the hiring process, you have to deal with people who will be with you for a given period of time, and so on.
Now, you discussed the situation that lead to your problem, but you haven't actually discussed the actual dynamic you're trying to change. Or if you're trying to improve your leadership skills, or what.
www.MarkTAW.com
Monday, November 24, 2003
Joel: Sounds a bit like Stockholm Syndrome to me.. :)
Steve P
Tuesday, November 25, 2003
And that's bad because? Just because you give Stockholm Syndrome a name, doesn't mean the underlying psychological principle doesn't work in other environments, or that they're permanently rooted in negative and manipulative environments.
Boot camp and fraternity hazing have a lot in common and both induce a feeling of loyalty. Boot camp is usually looked on from the outside as a positive thing, while fraternity hazing is often seen in the negative.
Most of these things are the glue that hold our society together, and only become a problem when they're specifically used for negative purposes, like unscrupulous sales tactics, or as you pointed out, Stockholm Syndrome.
www.MarkTAW.com
Tuesday, November 25, 2003
Yes, the idea of basic training is to get the recruit so scared of being berated and beaten on by his drill instructor, that he will do anything to prevent this from happening, eg kill the enemy
Dan G
Tuesday, November 25, 2003
Dan, that's a very limited view of the world.
What's the purpose of fraternity hazing? So that the potential candidate is so scared of his brothers that he goes out and gets laid?
www.MarkTAW.com
Tuesday, November 25, 2003
Mark, what do you think fraternity hazing is for? It is to break down your former code of conduct and instill a new fraternity-centered code of conduct. Such thatt you give preference to your frat brother when the bank is hiring. Or so you don't turn your frat brother in when he rapes someone. Did you think group nudity, alcohol poisoning, cow tipping, and paddle spanking served some other, more holier purpose?
_
Tuesday, November 25, 2003
It seems I'm fighting an uphill battle here.
Adversity brings people together. You'd feel the same camraderie for people you'd worked on a particularly difficult project with, or survived a notoriously harsh professor at your university.
However the purpose of the harsh professor wasn't to cause kinship among his students.
This is probably a basic human instinct that helped us survive, say, the Ice Age, or Dinosaur attacks (I'm being anachronistic, I know). It's also the force that keeps immigrant communities insular, and allows them to trust each other almost implicitely, even when the other person is a complete stranger who just happens to be from your country.
It seems, though, that people here have such a single minded hate of fraternities and the military that they can't see past their own prejudices to a wider and more profound understanding of the world.
www.MarkTAW.com
Tuesday, November 25, 2003
Well it needn't be so overt as screaming at someone that they couldn't code the terminating condition of a loop to save their life.
There are other ways to build teams as well. To identify a common enemy, usually 'Them', or a corp d'spirit.
One method I've employed is to create a background project that had nothing to do with what was needed to be done, where time had to be stolen, either from their personal time or in some slack time because they were waiting on someone or something to happen. The background project was for the whole group though and there was no stratification as to who was in charge or responsible.
It has to be interesting enough to encourage them without becoming a drag on the main issues. And sometimes remarkable things would pop up that could be used generally.
Simon Lucy
Tuesday, November 25, 2003
What's anachronistic about dinosaur attacks? Dinos are nasty little buggers with sharp teeth.
Frederick Granite
Tuesday, November 25, 2003
Eli, is it really that hard to convince programmers of the value of what they're doing? As a civilian, I've always been led to believe that one of the great strengths of the U.S. armed forces (in addition to overwhelming /force/) is its logistics. I mean, all the fancy expensive hardware doesn't do much good if you don't have enough diesel to keep the tanks running and the planes in the air, plus the people to keep equipment serviced, the troops fed and watered, etc.
I would tend to think that anyone who went through basic training would have a pretty clear understanding that wars are won not just on the front lines, and that those admittedly un-sexy HR and resource-management systems can literally contribute to the life or death of their fellow soldiers. (Am I being melodramatic?)
That said, I can only imagine what the bureaucracy must be like at times in an organization that has literally millions of "employees" :-)
John C.
Tuesday, November 25, 2003
Simon, could you give me an example of this background project?
www.MarkTAW.com
Tuesday, November 25, 2003
The most successful one I had was with a Support Department I managed. Granted its a different kind of department but the problems of tedious code maintenance can be similar.
I gave them the challenge to produce a digital animation for an upcoming computer show that happened to be our biggest of the year. This is when there were very few tools to do this.
They storyboarded it, created the graphics, wrote an animation, page flipping app and along the way wrote a vector program to calculate the path of the Data Pac (basically a rectangular box) to move from background distance to foreground in a nice looping arc.
The whole animation lasted about three minutes and occupied them on and off for around 4 months, all of the time was either their.
About all I did was give them the space to do it and make suggestions, most of which they ignored I think. The guy that wrote the vector program was actually the Librarian who spent most of his time duplicating ROMs and disks.
It was a considerable success.
Other projects with other groups have been less ambitious and usually along the lines of 'I hate something or other about some internal process and can someone rid me of this troublesome priest'. So sometimes they can get a bit obscure.
It has to be at worst tangential to the everyday work and at best completely recreational. It could even be some version of Quake using the organisation and building as the setting and blowing away the CTO/CEO. :-)
Simon Lucy
Tuesday, November 25, 2003
Not all armies, or rather sections in the army, are the same. What works for combat boot training can't work for a team of developers. At least I don't think so. For this to work, my "code-troops" would need to live together up each others' butt for long periods of time without vacation,
preferably in tents, and all the other teams in the surrounding environment would have to be using
the same no-positive-feedback techniques. None of those can be achieved, and in any case, I don't think that this is the way to get creative work out of people.
I wanted to get a feel of the conversation before I said anything about the real things I am trying to resolve. I wanted to see what would seem the most important issue to deal with for you guys and it seems that the entire thread concentrates on the motivational and teamwork issues. Those things actually work out quite alright in my team. I am not that much older than my programmers, and I keep and open-door-with-a-smile policy, so most feel comfortable (or lie to me very well :). I try to stay out of subteam leaders' hair as much as I can and let them run things as they see fit and that seems to work fine. Besides, I myself am an old-timer, so I know enough technicalities to be able to manage things through knowledge of what I am doing.
One of the more complicated problems I'm facing is the frequent exchange of personnel. If a newbie stays on the project for the entire 6 years of his/her service, their motivation descreases over time, because there is a limit to the diversity of work in a single project. If, however, I want to start out with a more experienced programmer, I can get him from, say, a parralell project, but for at most 3 years (they've been at the other project for 3 years, and have another 3 to go).
Like any other project, there's a need for good coders, good designers, and good subteam leaders, and one person can't really do more than one thing effectivelly. The problem is that many times the same person is the best to do all three.
Coders are the easiest. With enough management resources and a good designer you can get almost anyone to code almost anything, as long as it is limited to a particular platform/language. But things are rarely that simple. Usually there are a few technologies involved, often connected in some bizzare way, and other skills are required. I have noticed that fresh-out-of-university graduates can usually write fantastic code - on a piece of paper. For some reason, probably due to the teaching techniques used in universities, many lack the most basic understanding of the computer as a whole and when it gets to actually implementing things using real API's, they get stuck. It's like knowing how to caculate the heat produced by the explosion in an internal-combustion engine and not knowing on which end of the car the enigine is.
So, most of the time I start with people who can write reasonable code, but have little overall understanding and whose computer knowledge is generally narrow.
Let's get to the concrete issues then.
A : How do you turn a regular person into a computer geek?
How do you define a power-user? How do you get people to the point of actually being one with the computer and not fighting a constant battle against it? It's a bit like teaching my mom to use a word processor, but on a completely different level. Unforunately I stumble upon this problem more often with women, than with men. I have no idea why is that, but it just is. Maybe the ladies here
might have some insight on this, or at least explain in great detail why that remark makes me a shovinist pig.
B : How do you train a good designer?
A good designer is someone with diverse experience, knowledge of multiple techonogies, with a solid coding background and a genuine interest in the field. A person who reads magazines and websites, who is as fluent in C++ as he is in English (or the appropriate language for the country) and who is willing to stand on his own in a technical debate.
There is a cerain amount of talent that is involved here, and not everyone can be everything. But I strongly believe that most of those things can be taught. In most environments you can just hire someone who is already all of the above. What I need, is to take a programmer, a good one at that, and divise some ingeneous scheme to make him a good designer, and do it fast. If I can't do it in
under 6 months, it's not going to help me much.
I'll leave the team leader training to a later discussion as it is, in my view, much more intuitive then the training for the previous two roles.
C : Now we get to the knowledge preservation problem.
It's like spec-writing, or flossing. Everyone knows that knoledge must be preserved regardless of the actual people that hold it, and noone actually does anything useful about it. In most organizations you can keep people working for you for a long time, so the problem is decreased. I, on the other hand, have a stop watch over my head. If I haven't preserved some knowledge and the
person is gone, so is the knowledge he had. The problem is that all the knowledge management techniques I am familiar with are very time consuming, programmer-frustrating and have a very short term of applicability due to the quickly changing environment.
Those are some real issues I am trying to find solutions to. There are others, but those are the most important, especially in terms of the future of the project.
Eli Golovinsky
Tuesday, November 25, 2003
John,
You are immensly melodramatic. People don't tend to think in terms of the good they are doing for their country. We live in egoistic times, everyone just thinks what he/she can gain personally. One of the things I find motivating is convincing them that one thing or another will actually boost their carier when they are discharged.
And I don't serve in the U.S. army, niether do I live in the US. It's some other country, but like I said, most armies are similar along the main lines.
Eli Golovinsky
Tuesday, November 25, 2003
Simon,
Although your idea is fascinating, I can't seem to wrap my brains around the "how to make it work" concept.
If you give people something more interesting than their work to do, they'll do it. INSTEAD of doing their work. I don't see how you could have a side project going on a still keep the folks task focused and produce qality results on schedule.
People sometimes tend to do things that don't exacltly fall withing the main goals of their job (like playing Solitaire or writing long JOS forum messages).
Adding to the amount of that doesn't sound very promising.
Eli Golovinsky
Tuesday, November 25, 2003
Simon,
I'd actullay like to hear more about that common enemy thing. Do you mean the "management" under 'THEY'? The customers? The competitors?
And what's that vague corp spirit everyone is talking about? Is it something that can be generated, or is it something that just "becomes" as time goes by?
By the way, there is no competition. As there is no money.
Eli Golovinsky
Tuesday, November 25, 2003
re: motivation, I'm reminded of the following story (paraphrased best I can remember).
One day a villager happened upon a construction site where 3 stonemasons were busy at work. He asked the first stonemason he saw what he was doing, and the stonemason replied "I am laying bricks". He walked around to the second stonemason and asked him what he was doing, and the stonemason replied "I am building a wall". Lastly, he walked over to the third stonemason to ask the same question. The third stonemason replied "I am building a house of God".
Same task, viewed 3 very different ways.
ted
Tuesday, November 25, 2003
Eli:
Why do you say we live in egoistic times? Do you imagine that in days past people were, on the average, more selfless? My limited study of history shows no indication of this.
Name withheld out of cowardice
Tuesday, November 25, 2003
No I don't. But egoism can take different shapes and some are less selfish than others. It is true, from my pespective at least, that there are less and less people who are motivated by some obscure ideology and would sacrifice something in the name of that ideology alone. And don't get me wrong, I have nothing against that, that is what true freedome is all about - acting the way that serves your own best interests. But it should be applied to the way we view motivation. I believe that you can very rarely use some distant global (even moral) goal as a motivation technique. We just all brick-layers, and we consider ourselves as builders of "a house of God" only if we are managing the whole thing.
Eli Golovinsky
Tuesday, November 25, 2003
On how to keep the background, reward project in its place:
Largely its a management issue and its pretty much why I didn't get deeply involved in the animation project (much as I wanted to), so that I didn't lose a sense of perspective.
Plus it was a self limiting thing, they knew that if it detracted from the main job in hand that I'd have to stop it. Now that's not to say that at some point someone didn't spend more time on it than they should, but if they did their work didn't suffer and overall morale rose considerably at the time.
So, as far as I was concerned it was a win-win.
Simon Lucy
Tuesday, November 25, 2003
'Them' is any external group that affects the work of your group. It might be someone in a customer relationship, it might be a supplier relationship it might be a parallel department or organisation (Army v Navy).
Often the best 'Them' is at least 2/3 levels above in the heirarchy and somewhat dim and remote in the minds of most of the group. So in that sense they'd be handing you specifications or requirements and then require timetables that made acheiving those goals challenging.
For a while I worked in an R&D Group and then its sister Product Support Group, the latter was set up to criticise and challenge R&D, in some cases it would compete with it to solve a problem. The original heads of these groups cultivated an air of animosity between themselves personally, both groups tended to protect themselves but also on a personal basis interrelated fairly well.
There was an Us and Them, a counter balance.
Now because of that Us and Them, the groups created their own esprit de corp (use the right phrase this time, Simon).
This still has to be managed and to a large extent the senior managers have to maintain a fictional animosity because in the end you have to cooperate and you have reasonably similar goals.
Ray Noorda coined the term coopetition, a kind of amalgam between cooperation and competition. In his view it would grow the market if rivals cooperated over fundamentals and competed over delivery, price, functionality.
Simon Lucy
Tuesday, November 25, 2003
On ensuring that knowledge is kept when individuals may move:
In fact, the average developer group in a regular business is going to have more of a problem with the loss of knowledge than military groups where you know pretty well how long they're going to stay. Not that companies manage knowledge that well at the moment, but many developers spend no more than 12 months at a particular site or organisation.
Something like Fogbugz used as a knowledge gatherer can help, I write some specific domain knowledgebases, but the fundamentals are the same. Make it as simple to record knowledge at the time its discovered and make it even simpler to find it afterwards. It has to be viral.
The best place to collect knowledge is within the process itself, in software that's the application, in software development that's the Bug tracking software.
Not that all knowledge comes from a bug :-), but I think its important to collect more than just bugs in bug tracking; usage, behaviour, thoughts ideas, maintenance commentary and so on.
Simon Lucy
Tuesday, November 25, 2003
"We live in egoistic times, everyone just thinks what he/she can gain personally."
Eli, John is not being melodramatic - you are being cynical. Perhaps this is the way you see things but it is a disservice to those who serve under you to assume they all have this viewpoint.
In the US military, this is generally not true at all.
Dennis Atkins
Tuesday, November 25, 2003
Simon's idea sounds better than mine, which is to have the new hires interview the people who are going to leave and create documents - according to some style guideline - of all the knowledge they have.
A : How do you turn a regular person into a computer geek?
Get them to love computers.
Simon mentioned Army v. Navy. Earlier I was thinking of robot soccer, are you familiar with it? Some of the best robotics engineers in the world try to design robots that can beat others in soccer, with no human involvement once the game started. Similar to the background project, can you get competing teams - and you only have 3 months to do this from when you're hired and it has to be in your spare time, to, say write a bot that will play Doom against the bot from the other team? Or build a computer from breadboard and a 9 volt battery that will literally fry the circuits of the competing team's computer?
Again, if you think it's too silly to use games directly, indirectly introduce them into the work ethic using real projects. Say, you want two presentations on how to proceed on project X or Y and the winning team's ideas get implemented. Of course you don't say winning either, you say you're going to form two committees to study the problem, and chose the best proposal. Then geniunely reward the team that one, nobody would write a good proposal if they were "stuck" with the grunt work afterwards and saw it that way. Perhaps a level of ownership in the project, a legacy where their name is attached to it for all time in the documentation and commented in the top of the source code.
B : How do you train a good designer?
You negate the "train" idea in your first sentance... "A good designer is someone with diverse experience, knowledge of multiple techonogies, with a solid coding background and a genuine interest in the field."
All of those things require time, which you don't have. So assuming you can't train "fluent in C++" you want to train reading habits and debate skills. Wouldn't the best way to do this to be by devising debates that require extensive reading to support your claims?
Since you guys write all your in-house software, you can use pre-existing baises within your team (ASP v. PHP) to fuel debates. When you get a new project, tell them you want to know what language they want to implement it in, and you'll give them 3 days to research their position. Then pit the ASP people agains the PHP people.
C : Now we get to the knowledge preservation problem.
As I mentioned before, you can have the new hires write the documentation by interviewing the people who are about to leave, though it occurs to me that this would lead to a very sloppy job if the people involved are lazy.
I agree with Simon here, make knowledge preservation as easy as possible. In fact, bake it into the process. When someone works on a task, their task should be recorded, and their solution should be recorded a well.
You might see this as a tedious process, or you might see it as a way to reward your employees for the things that they do. Surely some people already in the organization will see this as an invasion of privacy akin to the dreaded time tracking, but if you acquire (or write ... again an opportunity for some friendly competition and glory) something like FogBugz and put tasks in there, and find a fun way to get everyone to use it, ought to take care of the documentation problem. Maybe people will start to feel good about crossing things off their to-do list, and if they interact with the business people who give the requirements both over the phone/face to face, and through this system, it's a chance for them to get direct recognition from those business people for their efforts.
Maybe you can build an ebay-esque "coder rating" into it. Completely arbitrary because nobody will give bad feedback (unless it can be marked as private - for your eyes and the coder's eyes only), but a great way to get praise for your work.
www.MarkTAW.com
Tuesday, November 25, 2003
"Make it as simple to record knowledge at the time its discovered and make it even simpler to find it afterwards. "
I don't think that can be classified as knowledge preserving. What you preserve here is information, as in written text that no matter how easily accessible through a search engine is just not readily available in a person's mind to be used in a debate.
Without getting into the formal differences between knowledge and information (and I'm not too fluent in the formalities), I'd say that what is lacking here is the part where the information actually gets into the memory of new recruits.
You can't have them read the entire bug database. Aside killing themselves out of boredom, they will probably learn very little.
Eli Golovinsky
Tuesday, November 25, 2003
Joel,
You said something about a creative writing course for people who are not good engough at writing documentation/specs. This sounds like a solid idea that can take some of the downs of documenting out of peoples' minds. As with everything else I would have to try and implement a sub-version of such a course in-house. Any ideas on how to do that? Maybe read some Ayn Rand? :)
Eli Golovinsky
Tuesday, November 25, 2003
Dennis,
I assumed that the way the US military is portrayed in the blockbusters, as one big smoochy for-god-and-country idealogically devoted group, was far from the truth and probably more like things I am familiar with.
If I was wrong, then I was wrong and I appologize.
Eli Golovinsky
Tuesday, November 25, 2003
"So in that sense they'd be handing you specifications or requirements and then require timetables that made acheiving those goals challenging."
Doesn't sound like the kind of "Them" I would like to use for motivation. Noone wants to do work for some people high up the ladder that usually have very little clue on what is really going on, and make (at least in the eyes of the programmers) very stupid decisions. "Fighting" "Them" might easily transpose into "I'll show 'em, lets see what they do when I'm not on schedule!".
A peer type of "Them" is a much better choice, and the coopetition you mentioned seems to sum this up quite right. I was toying with the idea of letting each team choose a color, and create a soccer-like color fanatism.
Eli Golovinsky
Tuesday, November 25, 2003
Resentment of those that produce Requirement documents (and especially deadlines) is pretty normal. But you can turn that into a motivational good.
You have to stand in front of them and let them know that you'll protect them but you can only do that if they do their part. Its a fine line walking between what is possible and what is a fantasy and imparting a belief in the people that have to do the job to actually achieve it.
Simon Lucy
Tuesday, November 25, 2003
MarkTAW,
Wow, that's one long comment.
Using new recruits to properly document things that old-timers have done is actually a nice, workable approach. That way, you don't just store away information to come up at some random search, you actually make the newbies learn a particular subject to great depth. And there is less chance for frustration among the young because they are, hmmm, young.
As a matter of fact that was exactly what my fist task was when I joined this project. I had to reverse-engineer a few tens of thouthands lines of code and write detailed documenation about it. I hated my manager's guts for a very very long time, but I learned an enormous amount during those six months. BTW, that manager and me get along fine, now that I'm in his shoes and understand quite clearly why did he make that decision.
Games. Somehow integrating games into the workflow sounds odd to me, but I'm willing to give anything a try. I must say though that writing a Doom bot sounds extremely counter productive in the short term (it would never really be done on their free time). It may however prove very effective in the long term. Or not. They might get used to coding cool bots and games, and have no will whatsoever to write real code for real applications. But like I said, I'll give it some thought. It's an original enough idea to have a chance at being awesome.
Wow! A debate. That's one hell of an idea! I was always thinking along the lines of giving someone a task of teaching some subject, which, in turn, requires that he learns it extensively. But a debate is much more motivating. Put two teams (of one perhaps) on one subject, and let each come up with a solution. And then have a face-off. I like that. Another one to the list.
Didn't get your point on ebay raings. Do you mean allowing people to rate "was that helpful" for each information piece, and then have a contest over the usefulness of someones writings?
Eli Golovinsky
Tuesday, November 25, 2003
If you're uncomfortable with actually using games, use work in a friendly competitive way. Challenge them to refactor some code in their spare time - a legitimate work problem, but not one that needs to be addressed immediately.
Re: eBay ratings. If you implement a bug / feature tracking solution, why not tie a rating to each bug / feature? This is similar to Google Answers, now that I think of it.
I submit a bug or feature request into the system.
You accept responsibility for that bug or feature and work on it, and return to me a working solution, including the necessary documentation for someone else to work on it next time.
I close the ticket item AND leave feedback about what a great job you've done.
All of this is within the project management / bug tracking system. FogBugz meets eBay.
You get positive feedback for each piece of work you accomplish, and it encourages you to take on more responsibility because each positive thing you do is recognized.
This was along the lines of "keep everything in a project tracking system and keep the documentation in there" but also with the added motivational system built in.
You do have to think, though, of the end of the year consequence of keeping such a public system. People will think their compensation and promotion prospects are somehow tied to it, and the person with the fewest (but most difficult) tasks will be afraid that he'll be overshadowed by the person with the most (but easiest) tasks. You could build in a difficulty multiplier to be fair, but at that point you're acknowledging that this is a performance metric tool, and the game kind of falls apart and becomes work.
www.MarkTAW.com
Tuesday, November 25, 2003
Now that I think of it, simply removing the positive / neutral / negative ratings and leaving a blank feedback field might be good enough to motivate some people, though keeping track of your wins as if it was a score in a football game, especially if it is tied to a reward (trophy? gift certificate? - anything that spells out recognition from your boss & peers) can make work more fun.
www.MarkTAW.com
Tuesday, November 25, 2003
The Fogbugz example:
Yes they're recording information, but they also record knowledge. This situation came up, X happened, Y was done, etc, etc. It doesn't matter if its recorded more than once, in fact systems like Fogbugz and Bugzilla let you maintain strings of comments along with attachments and the rest.
As an example, if you look at the Bugzilla database for Mozilla and do a search for "profile password" you'll find an issue with a long screed about the rights and wrongs of putting a password on a profile. Pretty much all the arguments for and against are reflected in it and the system and philosophical reasons for not doing it in the end are all laid out.
Simon Lucy
Tuesday, November 25, 2003
You have the easiest job in the world. Here's what you should do:
I) every morning shout at all of your subordinate, pick one and critisize him/her in a way that he/she would start sobbing.
II) Threat. Tell them that if they don't do what you're asking them in a specified timeframe, you WILL break their neck. You should at least break couple of necks to prove that you mean business.
III) Critisize them no matter what. If they accomoplish something, pretend as if it was their duty. NEVER EVER AWARD, IT WILL SPOIL THEM
IV) HAVE A QUATERLY PHYSICAL DISCPLINE. THIS IS EXTREMELY IMPORTANT. The'd know that you really mean business.
V) Make sure that you put more pressure on them when it's their birthdays or anniversary, etc.
Do this and you'll be a happy camper
Cold somewhere in time
Tuesday, November 25, 2003
It seems to me that this type of knowledge management is only beneficial in larger organization than the project I work on. Unfortunately I don't have enough influence on peer projects and I they don't seem to utilize those technics.
About two years ago I started collecting knowledge. It was my own knowledge at the time, but later it became an Outlook public folder with the cumulative knowledge of the entire project. I still hold about 90% of the articles there, but that's besides the point. It isn't used enough. Actually, most of the occasions people read something that is written there, it is because they asked me a question, and I have already written a solution to it there and told them to go look it up. Although it's been around for about two years, and I've been trying to advocate it's usage quite a lot, it doesn't seem to sink in, that a search there could save a lot of time. The main reason for this is probably its rather modest size. There are about 200 articles on various technical subjects in varying length, but due to the advancing technologies many of the pitfalls described there tend to get useless very quickly.
Having all the information about bugs, ideas and solutions in one easily searchable place can be a nice thing if people actually think that there is a chance in finding a solution or a reference to their problem. It seems that in a small organization it is difficult to turn the use of such a knowledge-base into habit.
Eli Golovinsky
Tuesday, November 25, 2003
Cold,
You can get people killing other people using those techniques, but in the bug-shooting business, I don't think those techniques will be aprporiate.
I am disregarding the possibly cynical nature of your post, because it is a concept that occured to me a few times, and many people seem to suggest it when they hear the word Army.
If you need to build a fence, and you are a very experienced fence builder with several dozens of large-scale picket-fencing jobs in your resume, and your employees are very young and illiterate - then you could use that technique. In our business, I need the input of the people that work under me. I might be SLIGHTLY more experienced then they are, but that doesn't mean I have all the right solutions. If I don't promote an open and free speech policy, I will have to make all the decisions myself, including the technical ones I might know little about. That will of course lead to development of really bad software and an incredible headache on my part.
So no, I won't shout at anyone saying "Write that 'for' loop now, you have 20 seconds to do it!"
Eli Golovinsky
Tuesday, November 25, 2003
What? you expect bunch of newbies to give input? oh come on give me a break.
If you need to upgrade yourself, do it on your own.
REMEMBER, there's no such a thing as democratic team building in army. You gotta be harsh, extremely violent and yet blazingly sharp.
Cold somewhere in time
Tuesday, November 25, 2003
You're right, getting a common knowledge base used is a difficult procedure. In the cacade of easy to find solutions to problems, asking someone is often the easiest. Witness the number of technical questions that could be Googled that get answere here.
When you Google something there's no gaurantee you'll find it in a form you can digest. At least in a forum you can ask follow up questions until you understand.
I'm surprised nobody has mentioned a Wiki, have you thought about a Wiki?
www.MarkTAW.com
Tuesday, November 25, 2003
A Wiki. For some odd reason that word keeps popping up here and there but I can't seem to get a firm grasp of the concept.
But before I ask, I Google. Be back in a few.
Eli Golovinsky
Tuesday, November 25, 2003
lol. A Wiki is a knowledge base that allows anyone to create a page, and anyone to modify or comment on an existing page. You can link topics and create overviews of categories with relative ease.
The original Wiki is on c2.com and pops up when you Google it. I also suggest you search the WikiPedia for an example of a well maintained Wiki.
http://c2.com/cgi/wiki?WikiWikiWeb
http://www.wikipedia.org/
I suggest you find one on hotscripts or sourceforge and install it and play with it as the best way of becoming acquainted with the concept.
www.MarkTAW.com
Tuesday, November 25, 2003
Wikis are 'Ok' but they tend to be structured such that no one knows whats in there.
The comment 'It isn't used enough.' goes along with my original point about it being even easier to find the information than it is to record it.
Basically you get hard, it becomes a rule that if anyone has a question (whether its internal or external) then before they ask someone they go look in the Bible, if it ain't there they find the answer (or even if they don't, not knowing something is as important as knowing it), then they have to put it in the Bible.
Then you get the same peer pressure that happens here, 'I want to know about X and Mrs Mopp', gets the answer 'Google returns 100,000 pages on that'.
Simon Lucy
Tuesday, November 25, 2003
Ah, well then.
To be honest, Eli, I think the reason your group is having morale and motivation problems is pretty clear, as is the solution. You must look within.
Dennis Atkins
Tuesday, November 25, 2003
"Spend a few weeks screaming at people. Nothing they can do is right. Make them stay in nights and weekends fixing little things. After a couple of weeks, start dribbling out small amounts of barely noticible praise." -- Joel on Effective Project Management
I found this to be a rather interesting comment made by Joel.
Dennis Atkins
Tuesday, November 25, 2003
Dennis, I think you should go ahead and suggest
"Zen and the art of group maintenance" huh?
Cold somewhere in time
Tuesday, November 25, 2003
Front leaning rest always worked for me. who cares if they are programmers, they are still soldiers.
Christopher Hester
Tuesday, November 25, 2003
"What works for combat boot training can't work for a team of developers." -- Eli
Eli, what you have said is absolutely true.
I think that fundamentally you have a bad situation there. In the US, research and development work is not done by privates with no background in research, recruited straight out of boot camp. The entire concept would be seen as absolutely absurd. Research is done by having contractors compete for bids and then require them to deliver functionality in return for glory and a OBSCENE cash payment. The contractors hire developers with experience and the very best contractors doing cutting-edge development hire lots of developers, giving them a subset of elite ones that can be put into skunk works projects where they define their own rules.
As it is, with a bunch of 19 yr olds who are unmotivated and blase and just 'doing their time', you are in the same position as a math teacher at an inner city high school trying to teach a 'special ed' class full of troublemakers.
The only person who has ever succeeded at such a task was Jaime Escalante (Stand And Deliver), and no one I know of has been able to duplicate his success.
I would read his book if I were you and see if you can get anything from it.
In particular, I think Joel's advice was absolutely imbecilic and I sorely hope he was jesting.
Dennis Atkins
Tuesday, November 25, 2003
Wiki does sound a bit unorganized and uncontrollbale to me. And I don't see what advantage it may have over a FogBUGZ implementation or something similar.
Simon, getting hard in the way that you describe - that is something I can agree with.
Besides, it has just occured to me that two years aren't enough. This method must exist for a longer period of time, so that there would be things there that no-one knows about. As it is right now, I know all the articles by heart, and it doesn't do me much good aside saving some time when I send people to read there.
Eli Golovinsky
Tuesday, November 25, 2003
Well a Wiki is somewhat disorganized, but you can create high level pages, and many Wiki's have built in categories so it's easy to categorize any page.
The advantage I see over a FogBugz type solution is that you can back-load data, or load data that doesn't strictly fit the problem / resolution model of a bug tracking system.
I would just guess that it would be easier for you to load your 200 document repository into a Wiki than a bug tracking system.
Philo uses FogBugz, I wonder what Philo thinks about it as a knowledge repository... Philo, oh Philo...
www.MarkTAW.com
Wednesday, November 26, 2003
Cold,
Like I said, there are different armies with different perspectives on what are the most effective ways to motivate personnel.
Do you think that mere age is what makes someone worth listening to his advices? Anyone could give input, and there are quite a few 19 yr olds that have given great input along the way. Depends on the person and his capabilities.
There's no way I can do ALL the thinking for a group of 12, and they'll just to the keyboarding. I believe that giving the guys responsibility over features, and be accountable for them makes a much better team than in the way you suggest.
Dennis,
I never said that morale or motivation was the most important issue. I mentioned that it's a little complicated to deal with because you can't exactly choose who works for you and there are less ways you can encourage them, but that's not to say I haven't got that end covered. I can handle drops in morale and lack of motivation, which is a rare engough incident.
What I am looking for are ways to take a given group of people whom you don't choose and make them a better team. I have different folks. Some are amazing super stars. Some are not. Some think better on a broader scale, some write better code. Some are just downright average. What I need/want to do, is propell each and every one to the peak of his/her excellence. For that end I am looking for techniques to improve the leerning curve and methods for knowledge preservation.
There are amazing things you can do with a person that you may think is a very average programmer if you put your mind to it.
Eli Golovinsky
Wednesday, November 26, 2003
They are not unmotivated. But the environment I work within is unique, and so it requires unique solution. I am not trying to make the best software possible on a world scale (although I think we're doing quite well), I am trying to get the best results considering the situation. Like I said, morale isn't a critical problem, besides, some comments here gave me a few new tools to tackale it if it happens.
Eli Golovinsky
Wednesday, November 26, 2003
I've opened up this discussion to see what the industry proffesionals have to say about the rather unique situation I'm in. And that I did. You gave me much to think about, and a few concrete techniques to try and implement.
My views on the right way to motivate high-tech personnel in a military environment remain unchanged, and I strongly believe that harsh discipline isn't the way to go.
Thanks for all your input.
And thanks to the guy that along with some spammy emails sent me a reference to Joel's site. For some reason it has never turned up while Googling the net.
Eli Golovinsky
Wednesday, November 26, 2003
regarding BOOT CAMP comments.
Actually, when i went thru bootcamp, I always thought the reason the Drill Instructor was so hard on us was the COMMON ENEMY SYNDROME.
If you want a group to work TOGETHER, try creating an ENEMY for them to all oppose. It might be YOU or it might be the schedule or upper management.
Also, what would be the penalty if you worked slower?
Remember the consultant's motto: Schedule, price, or features? Pick any two.
Perhaps you should view this at a long marathon, not a sprint. If you worked slower and took more time for training your programmers, etc. perhaps the work would be more fun.
You need some breathing room to implement any of the suggestions made here. Having a less demanding schedule might help that. (Or, if the higher ups are demanding a schedule, maybe you should ignore them).
Entrepreneur
Wednesday, November 26, 2003
Yes, in the environment you describe, what is the penalty for not producing? These guys have 3-4 years with you no matter what? Do they get fired or laid off ever? Does what they do here influence what they do after they leave you?
www.MarkTAW.com
Wednesday, November 26, 2003
Take a look at the Agile programming techniques and Steve McConnell's Rapid application development book, and use short iterations (inch pebbles) so on one can get too far off track without it being obvious.
Using that approach I would set up two or more teams and reward the team that does the best.
john
Wednesday, November 26, 2003
There is no actual penalty for not producing. But most (though not all) of the people (me included) would like to make a career in this business for them, so beeing a part of (or leading) a well known and successful project, should have a very positive influence on the resume and career oporunities.
Most folks do feel obligated to do their job, and try to do it well. But when the age and lack-of-experience factor is considered, their best might just not cut it. So I want to train them, and do it as effectively as possible while gaining motivation assets along the way.
I don't think I need a common enemy to stimulate good work. We have a common cause - make customers happy. It's not the money that they'll pay us (they don't), it's the smile on their faces and the thank-you emails we get that make us get going. I sometimes use the technique of asking some high ranking client official to write an email of gratitude to the person who helped them solve a problem and did it well. If that official is a respected one (and I try to choose them like that for that kind of request), it can make someone feel a great deal better about him/her and their work.
Eli Golovinsky
Wednesday, November 26, 2003
Eli, Above (http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=90355) you state your goals:
1. "take a given group of people whom you don't choose and make them a better team"
2. "propell each and every one to the peak of his/her excellence"
And you say your methods for doing this are:
1. "techniques to improve the leerning curve"
2. "methods for knowledge preservation"
I think this is the first time you really state your goals in this thread, and trying to inspire your workers produce at their peak is a noble goal. Though I do have to take contention against your methods. Rather than making assumptions about what the methods for getting a group of people to perform at their peak, why not ask specifically how to achieve your goal?
To this end I've created a thread (http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=90659&ixReplies=0) that asks just that. Though, my focus was more on the individual than for the group, feel free to redirect it.
www.MarkTAW.com
Thursday, November 27, 2003
Mark, to go back to my post way above and in response you to your reply - huh? I love the armed forces, was in the final stages of recruitment myself until I got an illness that permanently disqualified me from joining.
I was simply paraphrasing a vetern whom I'd talked to about the subject as it seemed appropriate at the time of the post - I don't see how it relates to my world view, be it narrow or wide?
(ok, so I should of mentioned it was a paraphrased quote, but, live and learn)
DanG
Thursday, November 27, 2003
DanG
You love the arm forces? you are what a jackass?
concerned about DanG's mental health
Thursday, November 27, 2003
Dan - no offense intended.
btw, you should be more consistent with your name "DanG" "Dan G" I searched for "DanG" to try to find your post but couldn't find it. I had to widen my search to just "Dan"
www.MarkTAW.com
Thursday, November 27, 2003
Hey, me too, I love the armed forces.
Anonymous Coward, you're the jackass.
Dennis Atkins
Friday, November 28, 2003
 Recent Topics
Fog Creek Home
|
