TechLeaders

Let's get creative with employees

TechLeaders — Wed, 15 Apr 2009 17:21:00 GMT

With limiting resources and having to do more with less it's important that managers inspire their employees to "think out of the box". This phrase has been used for quite awhile and now it may mean more than just a buzz phrase.

Entrepreneur.com has a great article written by, David Javitch, that has some ideas to managers inspire their employees.

Check it out here: Inspiring employee creativity.

Change must involve the people and must not be imposed on the people.

TechLeaders — Mon, 06 Apr 2009 18:37:00 GMT

I read this line on businessballs.com and it made me really stop and think. Often times when changes happens, or comes down the pipe it definitely involves people, but is it involving the right people, while imposing the wrong ones. In a perfect world everyone loves there jobs and companies want to produce a product, or service that helps the world and is not bother by stock markets, or shareholders. Unfortunately, this is not a perfect world and the reality is that business sometimes have to due what makes the best business sense.

Here is a great article one businessball.com on change management because as we know the only constant is change.

5 potential retention mistakes

TechLeaders — Thu, 02 Apr 2009 05:33:00 GMT

We've gotten some really good feedback both positively and negatively on the issue of retention during a recession. This is not an easy time for anyone, but there is always something to be learned. Like my father and grandfather used to tell me, "Tough times help build character." At the time this was the last thing I wanted to hear, but isn't lack of character what helped create this mess? Just a thought.

TechLeaders found a good article from Ross Blake that discusses 5 key mistakes that employers make in dealing with retention. I recommend taking a look and please provide your comments as to whether you have seen these first hand, or disagree with them.

http://www.goarticles.com/cgi-bin/showa.cgi?C=1507795

Ross Blake, the Employee Retention Manager, shows small to medium size employers, businesses, and HR professionals how to develop strategies to increase employee retention, and save thousands of dollars by decreasing employee turnover and recruiting and hiring costs.

8 ways to retain talent in a recession

TechLeaders — Tue, 31 Mar 2009 17:03:00 GMT

CIO Insight has a great slide show illustrating ways to retain your talent during this insane economy. With budgetary cut backs and other cost saving measures being put into practice it's easy to lose sight of a company's most improtant assest-it's people. Especially those who are needed to keep the ship afloat and productive.

http://www.cioinsight.com/c/a/Workplace/8-Ways-to-Retain-Talent-In-a-Recession/

Effective learning for you and those you manage.

TechLeaders — Tue, 24 Feb 2009 23:30:00 GMT

As companies tighten up and work groups/teams scale down in size we may find ourselves being asked to take on new roles and responsibilities. Some of us have even taken this economic downswing as an opportunity to stretch ourselves and take on new projects, which may require us to learn something new. I'm a big fan of change and I believe it can inspire growth as complacency kills.

I've been asked to research learning and effective ways to do so. In my research I found a great article by Kendra Van Wagner on About.com. She offers up some great tips on effective learning from a psychological perspective. These tips may be applicable to you, or your team especially if you've had to ask others to ramp up and take over someone else's project.

How to Become a More Effective Learner - enjoy!

Lost heads?

TechLeaders — Wed, 18 Feb 2009 00:52:00 GMT

I'm sure everyone is tired of hearing about the economy, layoffs and the stimulus package especially since we are bombarded by this news almost everyday. However, this is the current reality we are all living in and we must continue to be productive. Most managers I have spoken to recently have either lost headcount to hire against, have had to let people go, or both.

With a smaller team and less resources managers are still tied to goals, objectives and project timelines as if they were still running at full capacity. CIO Insight has some good tips for managing with a reduced headcount. Some of these tips are no brainer's, but good to share out nonetheless.

Enjoy and please comment if you are dealing with a similar situation and how you are managing.

10 Tips for Managing with a Reduced Headcount (link is fixed)

How do you stay in the loop and monitor your staff’s performance?

TechLeaders — Wed, 11 Feb 2009 23:43:00 GMT

Every manager and employee engages in some form of career discussion. There are many ways this takes place and they vary by company. We posed this question to Kevin S, Principle Program Manager, and he believes in the 1:1 method.

What have you seen work/not work and suggestions?

1:1s both scheduled and opportunistic. Also small group meetings. I try not to micromanage but I am clear that in order for me to best support them I need to have clarity on what is going on, what challenges exist, what is blocking etc. I also try to keep broad and work a lot with my peers and others that may have dependencies on individuals on my team. Get feedback and make adjustments as appropriate.

Kevin S. is a Principle Program Manager Lead with responsibilities on technologies that participate in core Windows Manageability. The technologies being developed are Group Policy, Advanced Group Policy Management (AGPM), Diagnostic and Recovery Toolkit (DaRT) and other new initiatives regarding managing the Windows ecosystems. Kevin has been working in the technology field, primarily software and support, since 1991 and has worked in many capacities.

Are you a coach who wants their directs to GROW?

TechLeaders — Fri, 06 Feb 2009 23:36:00 GMT

I come across quite a few management related blogs, books, article, etc...and I found this content from one of the many email lists I'm on. I read it and thought it would be appropriate to share out. I'm interested to hear feedback on this method and look forward to seeing other models/methods that this community comes up with.

Know the GROW Model

One of the most powerful ways managers can achieve business results through others is by adopting a coaching approach with their direct reports. The GROW coaching model provides you with a framework in which to conduct coaching conversations. It also provides a useful approach to conducting career discussions.

At each stage of the process, the coach focuses his or her efforts on these areas:

Goals Establishing what the person being coached wants to achieve, asking questions, and actively listening

Reality Exploring the current situation by inviting self-assessment, asking questions, actively listening, and providing perspective

Options Brainstorming a full range of options, empowering, ensuring choice, asking questions, and actively listening

Will Motivating the person being coached to commit to taking action, supporting his or her efforts, actively listening, and asking questions

Coaching Session Tips

· Career development coaching should focus on the individual’s performance, demonstrated skills, interests, behaviors and other observable criteria. You should avoid basing coaching on subjective judgments about the person.

· Use the four fundamental listening skills:

o Attending: Show you are paying attention by nodding and maintaining eye contact.

o Paraphrasing: Reflect back both the content and the emotion of what the other person said

o Summarizing: Re-cap key points and provide focus

o Clarifying: Asking clarifying questions to ensure understanding and gain more detail or explanation.

· During your coaching session, ask focused questions such as:

o Open-ended (what, when, how, where, which)

o Non-leading (How do you feel about…?)

o Clarifying: (Could you clarify what you mean by...?)

Change Management

TechLeaders — Wed, 04 Feb 2009 01:30:00 GMT

It's been said many times, "that the only constant is change, " and Heraclitus would agree considering his doctrine of change

being central to the universe. Everything changes and this means you may be a new manager, or you will be managing a new

team. Below are 9 questions to consider when taking on a new management role, or heading up a new team.

1. What matters most to you as a new manager?

2. How can you help to meet the needs of your new employees?

3. What sort of challenging and meaningful tasks are presenting to your team? Do these align with their goals as well?

4. How are challenging and meaningful tasks assigned to team members?

5. What are some of your new team’s greatest concerns?

6. How much responsibility are you willing to assign to your employees? How much decision-making power will they have? Are you going to micro-manage until you feel more comfortable with your team?

7. How does your new manager prefer to provide and receive feedback?

8. How does your preference to receive updates on work and how often differ than the last manager, or if this is a new team do you know how you want updates delivered?

9. What do you think are your strengths and weaknesses? Are there people on your new team that can play off of these?

Questioning as a way of life

TechLeaders — Fri, 30 Jan 2009 05:37:00 GMT

I would like to thank Rajesh who is a Principle Development Manager at Microsoft for providing the content for this entry. He poses a great question and scenario that I'm sure quite a few TechLeaders deal with on a daily basis.

There is a soft skills training available for employees in Microsoft titled "Precision Questions and Answers". I have not personally attended the training. Of late, I keep wondering if it will make sense for me to attend this training. Let me jump to the reason. Of late, I have been wondering as to how much of my job is purely based on sheer questioning skills. Here are some examples of questions that are part of my day-to-day activities:

"Hey, how is the next release on XYZ application coming up?" Vs "Hey, did you guys freeze on the design of your Rules Engine for the upcoming release of XYZ?"

Now, if I ask the first question, the developers (who are normally a shy breed and always want to valiantly fight till the last moment) would just say "It's going fine Rajesh". For the 2nd pointed question, the answer I would get is: "It's fine Rajesh; but just that there are two different thoughts on implementation of the object model changes". Now, that is a conversation opener. The second style of questioning leads me into further deeper conversations that will open up a whole new design discussion and debate. More on this particular design discussion with my team in my next bog.

In a structured program review, an inevitable question is: "What is the status of ABC component?". The typical answer from the developer is: "It's done". Now, if you, as a manager are going to be satisfied with this answer, you will go forward with other topics. Or, if you are a paranoid guy like I am, then you would ask the next "peeling" question: "What do you mean by 'Its done'?". Now, the developer might say something similar to this: "Well, I am code complete and the review and unit testing ONLY are pending". Now, this gives you a much more clearer picture of where your ABC component is. The fact that this answer would have just blown me crazy is a different topic altogether!! Whatever the answer, I have always found that "peeling" questions end up giving you a lot more clarity on where things are.

When I come to think of it, this has pretty much become the way I gather my information on all the apps that I am responsible for. After sometime, I realized that, just by asking a lot of questions (some of them meaningful and a lot more that are annoying to my team) I have built my knowledge on the apps that my team is working on. And on more occasions than not, it has helped me do some course corrections if things are not shaping up the way they are supposed to be. Sometimes, I used to wonder as to how I was sure a particular piece of code or a component was developed the way it was without even having looked at that code! Is it good or bad? I don't know. All I know is, it has worked for me and is continuing to work. Obviously, it is not humanly possible for anybody to look at all the code 70+ developers are working on.

Managing through layoffs.

TechLeaders — Tue, 27 Jan 2009 19:41:00 GMT

It more than obvious that our economy is in trouble and hopefully will we see an upswing in the second half of the year. Unfortunately, many of you have had to be the bearer of bad news and let employees go, or you have been let go yourself. This weakened economy is making it tough on everyone and while researching articles and content on how to deal with a layoff I read a good post on bnet.com here.

What advice can you give other managers that might have to let go of employees, or how have you or others dealt with the news. We are all in this together so any feedback/feedback would be appreciated.

The Differences Between Scrum and Extreme Programming.

TechLeaders — Tue, 20 Jan 2009 23:47:00 GMT

Scrum and Extreme Programming (XP) are definitely very aligned. In fact, if you walked in on a team doing one of these processes you might have hard time quickly deciding whether you had walked in on a Scrum team or an XP team. The differences are often quite subtle, but they are important in determining if you have the right people assigned to your team and how the project is managed.

I think there are four main differences between Scrum and XP:

Scrum teams typically work in iterations (called sprints) that are from two weeks to one month long. XP teams typically work in iterations that are one or two weeks long.
Scrum teams do not allow changes into their sprints. Once the sprint planning meeting is completed and a commitment made to delivering a set of product backlog items, that set of items remains unchanged through the end of the sprint. XP teams are much more amenable to change within their iterations. As long as the team hasn't started work on a particular feature, a new feature of equivalent size can be swapped into the XP team's iteration in exchange for the unstarted feature.
Extreme Programming teams work in a strict priority order. Features to be developed are prioritized by the customer (Scrum's Product Owner) and the team is required to work on them in that order. By contrast, the Scrum product owner prioritizes the product backlog but the team determines the sequence in which they will develop the backlog items. I've never seen a Scrum team not choose to work on the highest-priority item. And a Scrum team will very likely choose to work on the second most important. However, at some point one of the high priority items may not be a good fit for the sprint being planned maybe a key person who should work on it will be swamped by work on higher priority items. Or maybe it makes sense to work on a slightly lower priority item (let's say #10 on the product backlog instead of #6) because the team will be working in the code where #10 would be implemented.
Scrum doesn't prescribe any engineering practices; XP does. I love the XP engineering practices, particularly things like test-driven development, the focus on automated testing, pair programming, simple design, refactoring, and so on. However, I think it's a mistake to say to the team â€œyou’re self-organizing, we trust you, but you must do these specific engineering practices…. This sends a mixed message to the team that causes confusion. I love the XP practices but don't like mandating them. I want teams to discover the value on their own.

These are small and often subtle differences between Scrum and XP. However, they can have a profound impact on the team. My typical advice to teams is to start with Scrum and then invent your own version of XP. The XP practices are wonderful but they work best and teams commit to them the most stridently if they discover them themselves rather than having them mandated. I help teams do this in my coaching by asking questions like, Would this bug have happened if we’d been doing test-driven development? Would we have made that mistake if we were pairing?

I find true XP to be a small target off in the distance. If a team can aim at that and hit the bull's eye, wonderful. If not, however, they are likely hacking (e.g., refactoring without any automated testing or TDD). Scrum is a big bull's eye that on its own brings big improvements simply through the additional focus and the timeboxed iterations. That's a good starting point for then adding the XP practices.

Thanks to Mike for providing this great comparison.

Why Fail?

TechLeaders — Fri, 16 Jan 2009 23:48:00 GMT

Does your project and leadership fail due these process mistakes? How do you combat these? What do you feel the #1 reason for failed projects is?

(Which might come back to you, the manager, since you were leading the charge)

Overly optimistic schedules. The challenges faced by someone building a three-month application are quite different than the challenges faced by someone building a one-year application. Setting an overly optimistic schedule sets a project up for failure by underscoping the project, undermining effective planning, and abbreviating critical upstream development activities such as requirements analysis and design. It also puts excessive pressure on developers, which hurts developer morale and productivity. This was a major source of problems in Case Study 3-1.

Insufficient risk management. Some mistakes have been made often enough to be considered classics. Others are unique to specific projects. As with the classic mistakes, if you don't actively manage risks, only one thing has to go wrong to change your project from a rapid-development project to a slow-development one. Failure to manage risks is one of the most common classic mistakes.

Contractor failure. Companies sometimes contract out pieces of a project when they are too rushed to do the work in-house. But contractors frequently deliver work that's late, that's of unacceptably low quality, or that fails to meet specifications (Boehm 1989). Risks such as unstable requirements or ill-defined interfaces can be magnified when you bring a contractor into the picture. If the contractor relationship isn't managed carefully, the use of contractors can slow a project down rather than speed it up.

Insufficient planning. If you don't plan to achieve rapid development, you can't expect to achieve it.

Abandonment of planning under pressure. Projects make plans and then routinely abandon them when they run into schedule trouble (Humphrey 1989). The problem isn't so much in abandoning the plan as in failing to create a substitute and then falling into code-and-fix mode instead. In Case Study 3-1, the team abandoned its plan after it missed its first delivery, and that's typical. The result was that work after that point was uncoordinated and awkward--to the point that Jill even started working on a project for her old group part of the time and no one even knew it.

Wasted time during the fuzzy front end. The "fuzzy front end" is the time before the project starts, the time normally spent in the approval and budgeting process. It's not uncommon for a project to spend months or years in the fuzzy front end and then to come out of the gates with an aggressive schedule. It's much easier and cheaper and less risky to save a few weeks or months in the fuzzy front end than it is to compress a development schedule by the same amount.

Shortchanged upstream activities. Projects that are in a hurry try to cut out nonessential activities, and since requirements analysis, architecture, and design don't directly produce code, they are easy targets. On one disaster project that I took over, I asked to see the design. The team lead told me, "We didn't have time to do a design."

Also known as "jumping into coding," the results of this mistake are all too predictable. In the case study, a design hack in the bar-chart report was substituted for quality design work. Before the product could be released, the hack work had to be thrown out and the higher quality work had to be done anyway. Projects that skimp on upstream activities typically have to do the same work downstream at anywhere from 10 to 100 times the cost of doing it properly in the first place (Fagan 1976; Boehm and Papaccio 1988). If you can't find the 5 extra hours to do the job right the first time, where are you going to find the 50 extra hours to do it right later?

Inadequate design. A special case of shortchanging upstream activities is inadequate design. Rush projects undermine design by not allocating enough time for it and by creating a pressure-cooker environment that makes thoughtful consideration of design alternatives difficult. The design emphasis is on expediency rather than quality, so you tend to need several ultimately time-consuming design cycles before you finally complete the system.

Shortchanged quality assurance. Projects that are in a hurry often cut corners by eliminating design and code reviews, eliminating test planning, and performing only perfunctory testing. In the case study, design reviews and code reviews were given short shrift in order to achieve a perceived schedule advantage. As it turned out, when the project reached its feature-complete milestone it was still too buggy to release for five more months. This result is typical. Short-cutting a day of QA activity early in the project is likely to cost you 3 to 10 days of activity downstream (Jones 1994). This inefficiency undermines development speed.

Insufficient management controls. In the case study, there were few management controls in place to provide timely warnings of impending schedule slips, and the few controls there were in place at the beginning were abandoned once the project ran into trouble. Before you can keep a project on track, you have to be able to tell whether it's on track.

Premature or too frequent convergence. Shortly before a product is scheduled to be released there is a push to prepare the product for release--improve the product's performance, print final documentation, incorporate final help-system hooks, polish the installation program, stub out functionality that's not going to be ready on time, and so on. On rush projects, there is a tendency to force convergence early. Since it's not possible to force the product to converge when desired, some rapid development projects try to force convergence a half dozen times or more before they finally succeed. The extra convergence attempts don't benefit the product. They just waste time and prolong the schedule.

Omitting necessary tasks from estimates. If people don't keep careful records of previous projects, they forget about the less visible tasks, but those tasks add up. Omitted effort often adds about 20 to 30 percent to a development schedule (van Genuchten 1991).

Planning to catch up later. If you're working on a six-month project, and it takes you three months to meet your two-month milestone, what do you do? Many projects simply plan to catch up later, but they never do. You learn more about the product as you build it, including more about what it will take to build it. That learning needs to be reflected in the schedule.

Another kind of reestimation mistake arises from product changes. If the product you're building changes, the amount of time you need to build it changes too. In Case Study 3-1, major requirements changed between the original proposal and the project start without any corresponding reestimation of schedule or resources. Piling on new features without adjusting the schedule guarantees that you will miss your deadline.

Code-like-hell programming. Some organizations think that fast, loose, all-as-you-go coding is a route to rapid development. If the developers are sufficiently motivated, they reason, they can overcome any obstacles. For reasons that will become clear throughout this book, this is far from the truth. The entrepreneurial model is often a cover for the old code-and-fix paradigm combined with an ambitious schedule, and that combination almost never works. It's an example of two wrongs not making a right.

Have we learned from classic mistakes, or are we continuing the cycle?

TechLeaders — Thu, 15 Jan 2009 00:38:00 GMT

While doing content research for TechLeaders I came across an interesting list that describes some of the people-related classic mistakes in the software industry. The article was broken down into people, process, product and technology. Over the next several posts we will be sharing each category.

Please keep in mind that the studies and list are pre-2000 (thus classic), but we are interested to see if managers have learned from these "classics", or is history bound to repeat itself.

First Topic of the 4 part series:

People

Undermined motivation. Study after study has shown that motivation probably has a larger effect on productivity and quality than any other factor (Boehm 1981). In Case Study 3-1, management took steps that undermined morale throughout the project--from giving a hokey pep talk at the beginning to requiring overtime in the middle and going on a long vacation while the team worked through the holidays to providing bonuses that work out to less than a dollar per overtime hour at the end.

Weak personnel. After motivation, either the individual capabilities of the team members or their relationship as a team probably has the greatest influence on productivity (Boehm 1981, Lakhanpal 1993). Hiring from the bottom of the barrel will threaten a rapid development effort. In the case study, personnel selections were made with an eye toward who could be hired fastest instead of who would get the most work done over the life of the project. That practice gets the project off to a quick start but doesn't set it up for rapid completion.

Heroics. Some software developers place a high emphasis on project heroics, thinking that the certain kinds of heroics can be beneficial (Bach 1995). But I think that emphasizing heroics in any form usually does more harm than good. In the case study, mid-level management placed a higher premium on can-do attitudes than on steady and consistent progress and meaningful progress reporting. The result was a pattern of scheduling brinkmanship in which impending schedule slips weren't detected, acknowledged, or reported up the management chain until the last minute. A small development team held an entire company hostage because they wouldn't admit that they were having trouble meeting their schedule. An emphasis on heroics encourages extreme risk taking and discourages cooperation among the many stakeholders in the software-development process.

Some managers encourage this behavior when they focus too strongly on can-do attitudes. By elevating can-do attitudes above accurate-and-sometimes-gloomy status reporting, such project managers undercut their ability to take corrective action. They don't even know they need to take corrective action until the damage has been done. As Tom DeMarco says, can-do attitudes escalate minor setback into true disasters (DeMarco 1995).

Friction between developers and customers. Friction between developers and customers can arise in several ways. Customers may feel that developers are not cooperative when they refuse to sign up for the development schedule that the customers want, or when they fail to deliver on their promises. Developers may feel that customers unreasonably insisting on unrealistic schedules or requirements changes after requirements have been baselined. There might simply be personality conflicts between the two groups.

The primary effect of this friction is poor communication, and the secondary effects of poor communication include poorly understood requirements, poor user-interface design, and, in the worst case, customers' refusing to accept the completed product. On average, friction between customers and software developers is so severe that both parties consider canceling the project (Jones 1994). Such friction is time-consuming to overcome, and it distracts both customers and developers from the real work of the project.

Unrealistic expectations. One of the most common causes of friction between developers and their customers or managers is unrealistic expectations. In Case Study 3-1, Bill had no reason to think that the Giga-Quote program could be developed in six months except for the fact that the company needed it in that amount of time. Mike's failure to correct that unrealistic expectation was a major source of problems. In other cases, project managers or developers ask for trouble by getting funding based on overly optimistic schedule estimates. Sometimes they promise a pie-in-the-sky feature set. Although unrealistic expectations do not in themselves lengthen development schedules, they contribute to the perception that development schedules are too long, and that can be almost as bad. A Standish Group survey listed realistic expectations as one of the top five factors needed to ensure the success of an in-house business-software project (Standish Group 1994).

Lack of effective project sponsorship. High-level project sponsorship is necessary to support many aspects of rapid development including realistic planning, change control, and the introduction of new development practices. Without an effective project sponsor, other high-level personnel in your organization can force you to accept unrealistic deadlines or make changes that undermine your project. Australian consultant Rob Thomsett argues that lack of an effective project sponsor virtually guarantees project failure (Thomsett 1995).

Lack of stakeholder buy-in. All of the major players in a software-development effort must buy in to the project. That includes the executive sponsor, team leader, team members, marketing, end-users, customers, and anyone else who has a stake in it. The close cooperation that occurs only when you have complete buy-in from all stakeholders allows for precise coordination of a rapid development effort that is impossible to attain without good buy-in.

Politics placed over substance. Larry Constantine reported on four teams that had four different kinds of political orientations (Constantine 1995a). "Politicians" specialized in "managing up," concentrating on relationships with their managers. "Researchers" concentrated on scouting out and gathering information. "Isolationists" kept to themselves, creating project boundaries that they kept closed to non-team members. "Generalists" did a little bit of everything: they tended their relationships with their managers, performed research and scouting activities, and coordinated with other teams through the course of their normal work flow. Constantine reported that initially the political and generalist teams were both well regarded by top management. But after a year and a half, the political team was ranked dead last. Putting politics over results is fatal to speed-oriented development.

The #1 responsibility of a people manager is __________ (fill in the blank)

TechLeaders — Mon, 12 Jan 2009 23:39:00 GMT

Empower and Grow individuals! I am very passionate about this. I fully believe that everything else I am responsible for takes a back seat to making sure the people on my team can be successful and move forward in their careers. That those individuals can get opportunities that provide the right experiences so that they can achieve their full potential. This can be tough as a front line manager as there are quite a few IC responsibilities that need to be addressed. I tend to try and delegate as much as possible so that I can fully focus on people management and growing my team.

Kevin Sullivan is a Principle Program Manager Lead with responsibilities on technologies that participate in core Windows Manageability. The technologies being developed are Group Policy, Advanced Group Policy Management (AGPM), Diagnostic and Recovery Toolkit (DaRT) and other new initiatives regarding managing the Windows ecosystems. Kevin has been working in the technology field, primarily software and support, since 1991 and has worked in many capacities. Working with ISVs over the past many years Kevin has been able to bring to market some key enabling technologies that help customers better manage their Windows environments and their Active Directory deployments.