Saturday, March 24, 2012

Managing and Motivating Developers: Tips for Management Cluefulness

Developers want managers who'll help them solve business and technical problems, who'll protect them from unnecessary office politics and who will help them meet their personal career goals.


But programmers are...different. Like musicians, these creative folks can alternate between big-picture thinking and persnickety detail in a heartbeat.


Тom DeMarco's Peopleware 


 Harvard Business Review essay called "Who are your motivated workers?" by M. Scott Myers, written in 1964 (vol. 42, issue 1, pp. 73-88,



recognize their own and their team's abilities, and trust them to get the work done. ("Try and challenge me. I'm so much more than what you use me for,"



Ilja Preuß software developer at disy Informationssysteme GmbH. "The most motivated people are those who do what they like doing."



 "Techies need time to think as well as doing the code," says Lotus Notes guru Ben Poole.



Instead, give developers the big picture. "The more work I am assigned in advance, the better,"



To many, the manager's most important role is to protect developers from office shenanigans



Limeback says, "to take care of all the corporate crap, useless meetings, paperwork and other time sinks."



Jim Pensyl, a senior performance engineer, "The more you cave to marketing time lines and avoid realistic estimates, the more you set yourself up for a project that will extend beyond marketing's promised date."



 "Get out of my way. I know what I'm doing." Many developers say they work best with people who give them problems to solve and do not interfere with how the individual solves them.



Developers don't necessarily expect that the boss will understand what they're doing. They do, however, want the boss to listen and respond to her staff before making decisions.



"Chat with the people who do the work once in a while. See what motivates them, and perhaps even get an idea of what it takes at their level to complete a project," IT professional Michael Furmaniuk



"Listen actively, speak openly" 



Be specific; subtlety is often lost on developers who are very cause-and-effect oriented. "Non-directive" suggestions aren't helpful, since a developer may not have any idea what you're hinting at.



"Verbal praise works for me,"  "Even if I'm not the best, I still need some positive talk to move me."



But feedback isn't always about telling developers how good they are. It's about setting expectations and being both consistent and fair



 "At the root, all problems are people problems. Consider the people first, and the technology second."


The Difficult One: Pay Developers a Lot of Money.


keep an eye on what the job market is doing for his role, and make reasonable adjustments to ensure the staff is within the comfort zone for their pay scale


A Purr-fectly Reasonable Analogy


good IT people like cats

 "If you treat them well, offer the occasional special treat, and discipline them fairly, it can be done and done well. If you miss a point or two now and then, they'll adjust," he says. "If you miss any of these points consistently for too long, the really good ones will start to wander off in search of better opportunities."



micromanaging a cat is pointless; the results are frustration for both you and the cat



Make sure that the cat understands what you want.




If you've done a halfway good job of handling the cat, it will consistently surprise you by doing a better job than you can imagine, and often in ways that you would never have thought of and couldn't explain if you had thought of them!" he says. Plus, trying to understand a cat is highly educational, but rarely profitable because, after all, cats do what cats do. It is a bad idea to either over- or underfeed a cat, Phelan advises. "Overfed, they get lazy. Underfed, they'll do things you don't want them doing. Find the appropriate level for each cat. Always leave room for the occasional treat (some earned, and now and then one 'just because')."
Do not abuse the cats, he adds. They'll do things to get even that you'll never think of. Remember, too, that cats learn a lot by playing. Always try to leave them time to play. The exercise is good, the team building is good, and you often end up with better-behaved cats.

оригинал

Monday, March 12, 2012

The 5 Qualities of Remarkable Bosses

1. Develop every employee.
2. Deal with problems immediately.
3. Rescue your worst employee.
4. Serve others, not yourself.
5. Always remember where you came from

оригинал

Sunday, March 11, 2012

Top Executive Recruiters Agree There Are Only Three True Job Interview Questions

The only three true job interview questions are:

1.  Can you do the job?
2.  Will you love the job?
3.  Can we tolerate working with you?


Thursday, December 8, 2011

Tech Lead Checklist to Kick your Team into Gear

DAILY

Require written standup reports each day. Read ALL standup reports. If someone did not write a standup report, contact them by chat or email, and escalate if they do not respond.
Attend a daily chat. Ask for comments and issues. Make it short. Move long discussions offline.
Resolve any needs or roadblocks posted in StandUp by a team member in the scrum chat.
Look at the detailed activity report for each developer.
Move any request, agreement to a ticket/message/wiki. Do not rely on chat agreements because they can’t be tracked.
Let team members select their own tasks. Balance load. Do not let team members work on many tickets concurrently. A team member should select one or two tickets to work on and finish. The rest are available for others to select.
If someone has been working for several days on one ticket, without committing, ask him to split it into smaller tasks.
WEEKLY

Review all tickets for the current milestone. Add or move depending on schedule and capacity.
Ask specific developers to take the planning and task breakdown for complex tickets, features, stories. To distribute the load, you should also be getting mockups and stories/scenarios from a non-developer product owner.
Write and post a message about what the team did last week and what the team will do next week – a sort of scrum of scrums report
BI-WEEKLY TEAM BUILDING

Look at new developer applications and say who you are interested in. Someone else should handle the details of finding new candidates and then getting them started.
Do “onboarding”. Make sure each new developer has the information he needs, a development environment, and a simple task. Help the new developers to update the setup documentation. Send them contact information and an outline of the daily requirements (standup, chat, commits).
Evaluate trial developers near the end of the trial period. Look at all of their work, and evaluate productivity and quality. Write a little review. Say whether you want to continue working with them.


оригинал

Friday, December 2, 2011

Lean For Mechanics – LeanGiving in the Real World

Visualize the work flow and limit each mechanic’s work
Have nightly check-ins to plan for the next days work
Conduct retrospectives at the end each week for continuous improvement

First, expert mechanics were doing low cost, routine jobs like oil changes instead of high performance jobs that brought in more revenue.
Second, mechanics spent overhead time ordering parts (instead of the service manager) rather than revenue generating time working on cars.
Third, a large backlog of cars were stacking up waiting for a mechanic to become available.

оригинал

Thursday, December 1, 2011

Why Software Projects are Terrible and How Not To Fix Them

Shouldn’t a little startup using XP be able to wipe the floor with bad companies in an hour? If all it takes is better engineering practice, shouldn’t the better engineers always win?

our industry’s best practices don’t make sense. I don’t mean, of course, that they aren’t objectively better–of course they are. But they are nonintuitive.

If the guy you’re talking too is thinking “This sounds like a really good idea but I’m concerned I can’t sell this upstairs,” you are dead in the water.

Put yourself in the middle manager’s shoes. If the project goes bad, he has to “look busy”. He has to put more developers on the project, call a meeting and yell at people, and other arbitrary bad ideas. Not because he thinks those will solve the problem. In fact, managers often do this in spite of the fact that they know it’s bad. Because that’s what will convince upper management that they’re doing their best.

My second theory is that business objectives can change faster than anyone can react.

Jobs was fired in 1985, but he was re-hired in 1997. That is twelve long years before they admitted their mistake.

Reality is slow.

They want results today. They want a PowerPoint slide to present at the meeting upstairs in ten minutes that explains how the project is back on track. They don’t want a real solution, they want smoke.

Actually writing better software doesn’t matter. What matters is stats.

If a prospect objects to being involved in the testing, starts editing your contracts line-by-line in pencil, and starts talking about penalties for missed final delivery deadlines and bugs,

run.

CTOs in mainstream companies still believe in function point analysis.

I would like someone smarter than I, to produce a software formula that balances these factors: Speed to Market, Profit, Cost, Happy Customer, Happy Stakeholder, Quality, Performance, Keep your Job and Happy Worker.



оригинал

The Joel Test: 12 Steps to Better Code

The Joel Test

Do you use source control?
Can you make a build in one step?
Do you make daily builds?
Do you have a bug database?
Do you fix bugs before writing new code?
Do you have an up-to-date schedule?
Do you have a spec?
Do programmers have quiet working conditions?
Do you use the best tools money can buy?
Do you have testers?
Do new candidates write code during their interview?
Do you do hallway usability testing?


оригинал