Gary Allison's Leadership Blog

Wow. Things have changed. I’ve been working with Indian Outsourcers now for over 13 years dating back to those early projects at IBM. In the last two years, I’ve seen costs drastically increase and the availability of skills dramatically diminish. This is now clearly a trend from my chair and worth some serious examination in this blog. Too much to cover in just one post, this needs a bit deeper treatment.

In our world, software outsourcing has become an integral part of the IT industry. It has lived, grown and matured to its full potential. Companies that wish to cut costs look upon software outsourcing as a boon. One of the most important factors that attract Fortune 500 companies to outsourcing is the element of savings attached to an outsourced project. Outsourcers claim an average reported 40-60% increase in net savings.

Among the destinations chosen for software outsourcing, India stands as the most preferred, apart from China. Ireland, Romania ad Philippines also come into play. Clearly, the British colonization of India in the 17th and 18th century set off a cascade of domino that created the current IT outsourcing bonanza in this country. By introducing the English language and a western style legal system, the building blocks were laid to make the current attractive environment possible.

There are a number of major benefits of software outsourcing in India, including cost efficiency, availability of skilled workers, adoption of quality practices, and ease of doing business through the aforementioned common language and legal practices (mostly).

The winds of change are now blowing however. The first two of these advantages of oursourcing are fast disappearing. We’ll examine these in greater depth here in subsequent posts, but I’ve seen over the last year, a rapid deterioration of the cost advantage and skill availability in India. In addition to the supply / demand economics driving up costs, the rapid swings in the exchange rate are taking their toll.

For example, during two months last year, the value of the Rupee increased an astounding 8.5% in just 40 working days against the US Dollar. Attribute this to economic growth of an incredible 8 to 9%, a rate only exceeded by China.

This incredible economic success has had the result of making some Indian entrepreneurs incredibly wealthy, and deservedly so. But it has also had the effect of dramatically increasing costs and increased competition for skilled and experienced software developers. I’ve seen rates for well-qualified candidates now approach within 20% of a US hire. The days of the 3 for 1 cost advantage are no longer. We’ll dive into more detail in upcoming posts.

Ok, so your want to startup or install self-directed teams.(see a previous post on change). As with any change, this is a big challenge and there is no guarantee that it will be accepted completely by the team. Some will be uncomfortable with accepting accountability, a strong Scrum master will be needed, and some just don’t like having to fit within a structured process. In our adoption of Scrum, a few things have helped us gain acceptance:

Training We are fortunate to have a certified Scrum Master on board who has trained the whole team. A full day of training was invested in every member of the team. Additional training is needed for Scrum Masters because their execution needs to be effortless for the process to flow.Executive Buy-in and Support All levels of management must support the process. The integrity of Sprint content must be held in tact for the process to work. During the sprint, business needs sometimes require us to trade Sprint tasks for backlog items, but the integrity is maintained if the team signs up to the change.Strong Leads that are Willing to take on Scrum Master role this process of self directed team still requires someone on the team to drive the process. In my experience, a strong and effective lead developer is one of the most rare and valuable commodities in the Software Engineering world.In short, the only mistake we have made with Scrum is not more quickly adopting the process everywhere in the team. At the end of the day, team success is the greatest motivator for this or any other change.

About 18 months ago, we adopted a self-directed process called Scrum in part of our development team – the part that focuses on end user applications.  Most of the team was a little apprehensive, but they are solid folks and they put it in action. 

 

Recently, we made the move to transition the whole team to Scrum, something I should have done long ago.  Initially, I believed that complex pieces of server-side software had longer life cycles, longer testing cycles, and therefore perhaps the Scrum process wasn’t a good fit.  I was wrong.  What we could have seen are the same benefits on the server-side that we’ve seen on the client.  So, now we are rolling it out team-wide.  So what are some of those benefits?

 

The most important benefit is the placing of ownership where it needs to be – at the team level and ultimately at the individual level.  Whether they are taking a turn at Scrum Master, or just part of the team, each person owns reporting on their progress, the whole team owns the sprint backlog delivery, and has the power to say no to things not in the Sprint.

 

Team planning and ownership of the deliverable by the team – each Sprint (we use a month), the team signs up to a number of developer days, test days, and Tech writing days available.  We estimate the line items in the backlog and allocate the available days.  Its all team driven, and as such, the team owns the plan for the Sprint delivery.  In addition, the team demonstrates the deliverable from last Sprint – a powerful way for them to show accomplishments.

 

Peer-to-peer accountability – another significant benefit.  With Scrum, there is no place to hide from missed deliverables, poor quality, and lack of skill.  Any team member can take any item of the backlog and work on any piece of the system. As such, Scrum breaks down artificial barriers.  And, with daily scrum meetings on what was accomplished and planned for each day, it is pretty easy to tell if someone isn’t pulling their weight.

 

Forcing the business to define priorities – Scrum forces a booked plan, reconciled to business priorities at the beginning of each Sprint, monthly for us.  It provides a systematic way to pull in all the business inputs (sales, marketing, support, et al) into the planning process – and enforces that this is there only chance to get input into the development cycle until next Sprint. (Not really of course, but it does force the conversation.)

 next Blog…. Success Criteria for Adoption of Scrum

The Second Law of Software Dynamics:  shipping software is a commitment, not an event.

Customers generally expect once they have adopted your software or service that you are going to continue to develop it, service it, respond to their requests for tweaks, and keep up with competitive forces.  In short, they made a commitment (time, dollars, training, or perhaps a key part of their business) to you, and they are expecting the same.

Yes, this applies to Web 2.0, SAS, and whatever the new paradigm of the day is. It is all just software in different cloth. It may be delivered in a different way, or have a new business model attached, but the commitment remains the same.

(What is the First Law?  Given any non-trivial system, as long as you test software, you continue to find bugs. I need to blog on when is enough, enough someday soon)

Do you watch Dirty Jobs on Discovery Channel? I have to admit, I think I’m hooked on this show. It might be the deadpan delivery of Mike Rowe, or could it be somewhat deeper? As a leader in software development, sometimes you can feel like the star in the PigWrangler episode (and no developers are not pigs). Bear with me as I take metaphorical license… Sometimes you have an uncooperative environment, and after the product goes to market, well, theres just a lot of poo to clean up. And, boy is there poo! Well, you’d just have to see the episode.

 In fact, the poo theme seems to run through many of the Dirty Jobs episodes. At the end of the day, in the midst of all the poo, there is a successful business. Art imitates life again.  In software development, there is more than a fair share of poo – changing requirements,customer promises of features that don’t exist, missed sales targets, layoffs, inept people at all levels (yes executive management too), pass-the-buckers, slackers, hackers, you name it. Face it – on any given day, we are all capable of poo. Still, out of all this comes innovation and products that people use every day. For many of us, this makes the job worthwhile, even when it’s a Dirty Job.

Lately, I’ve been interviewing to fill an open management position. Clearly these are positions of the utmost importance in that a great hire will push the team farther and higher, while a bad hire can be disastrous.

I’ve put together some question (but not all in case you’re next) I’ve used, and hope they are of help to you.What does a manger do? This will generate lots of conversation. Looking beyond the technical to an understanding of the business environment willingness to get up close with a customer and truly understand their need ability to ask the hard questions, whether with marketing/sales, or with software engineers. Above all someone who embodies characteristics of servant leadership. How do you distinguish between top performers and above average performers? What are some examples of how you have rewarded these top performers? Looking for bonuses, creative recognition, and monetary recognition that clearly separates the top performers.What has been your highest performing team? What made them that way? Looking for people who give credit rather than take credit.What has been the most difficult situation you’ve encountered in mgmt? What would you do different about it if you relived it today? Amazing what you can learn here. If they can’t think of one, they are not being honest or don’t have any real world experience!Have you ever needed to manage an employee out of the business for performance reasons? Describe this process.What gets you excited?What would your goals be for the first week on the job? (I know it is such a stock question, but its still a good one).What agile development processes have you used? Where were they successful and where were there problems?What qualities do you look for when you hire? (what I’d like to hear is: willingness to go the extra mile (commitment), examples of driving issues/opportunities all the way through closure, even outside of normal channels (ownership), demonstrated ability to innovate, someone that works well within a team and demonstrates a fair amount of personal leadership.So, how long have you had that wart? (just seeing if you are paying attention)

It just amazes me the creative and inventive ways people use to avoid goal setting.    Believe me, I’ve seen it all.  When it comes right down to it, most people would just rather not be held accountable.  And, to some degree, this is understandable.  Life is full of the unexpected – and software is a great example.  There are new technologies, new toolkits, new platforms, and just plain new stuff all the time!  Who can say in any degree of certainty, how long something will take.  If you are truly certain, then you’re probably not working on anything very interesting.

But, beware of the one who continually avoids commitment.  Enough said.

About measurement. … A goal is only worthwhile if you measure, reward, and learn from it.  If you are setting goals using a process like SCRUM, goal measurement is fairly clear.  I love this process because it provides daily feedback and peer-to-peer accountability of the type not possible to deliver hierarchically from management.  It just means so much more coming from your comrades in arms. At the organizational level, I’m a huge proponent of setting high level vision goals at a functional level each quarter of things that need to get done, and then validating these with each team.  Once each team develops the detailed goals supporting the vision goals, we can validate they’re achievable, refine them, and make them more specific. This reminds me, sometime I really need to blog on what it is like to develop software for Japanese customers.  I wonder… can my career survive that much honesty…. 

Do you see a lot of conflicts at work, people working at cross purposes, even though at their heart, they have a common desire for success??? In my view, many times this is due to organizations not having a common vision, common sets of priorities, and measurable objectives. Or, perhaps they think they have this common vision, but until they go through the exercise of writing it down, they don’t realize?how far apart they are.

 

Each quarter, it’s just required we agree on a set of objectives for the team that can serve as a guidepost through the quarter. These are not set as a absolute iron-clad whipping post list, but rather as a set of important deliverables which the team commits to achieve. For software,a quarterly set of deliverables is a list of external commitments that must be supported by project plans and processes that deliver during the quarter.

 

Goal and objective setting is a somewhat tedious process that I’ve yet to see someone actually enjoy. Its just not fun, but anytime we skip this step in the course of “just having too much on the plate”, we inevitibly pay the a much higher price.

 

More on Goal measurement next Blog.

 

Now, back to that goal setting for next quarter….

Driving to work this morning, I passed a lady in an SUV with her paperback and couldn’t help but wonder… Yes, you heard me, she was reading a paperback and driving. Not certain how well she was reading, but I can tell you her driving was impaired. This is not a rant about driving while doing stupid things, but rather some thoughts about how we decide what is important and what just isn’t.

 

One can only conclude this was a very important book to the lady in question. With the absolute deluge of information coming at us day-in, day-out, it is easy to become overwhelmed. Its astonishing in fact you are stopping to read this today in fact. It is easy for most leaders today to simply sit and answer email 10+ hours a day. Of course, this is productive in one limited sense: making and communicating decisions is a core part of what we do every day.

 

The essential question though, is how do we decide “What’s important”? This is the art of balancing the urgent vs. the important. It is terrifically easy to loose sight of the important in the face of the urgent. No more Covey-isms here, but it is so easy to say and yet so hard to do.

 In high-tech, I have seen myself and many others struggle with this. High pressure jobs put high demands on everyone. Still, a few things really help:

• Start each day reviewing your priorities (don’t start with email right away).
• Make sure that in those priorities, you have included something concrete for your children, wife, family, friends, etc.
• Is someone on your team really struggling with something? What can you do to help?
• What are your boss’ priorities? How can you best help him/her?
• What one thing can you do today to avert a crisis next week or next month? Do it.
• Schedule your personal time into your calendar well in advance and make sure people know they can consult your calendar for your availability
• Expect more from the people you work with. Are they working as hard as you are? If not, why not?

And, as for the lady with the book, I’ll let you know the first time I see someone watching their video iPod driving down the road. It’s just a matter of time.

Ok, so I’m a little late for the US New Year, but made it in time for Chinese New Year! It’s natural at this time of year to think about changes we need to make in our organizations, teams, and lives. This is not a self-help column, so I leave the latter to Dr. Phil. Software execs rarely have time the think, much less put together a web page. Thankfully, my wife has enabled me to do both this morning…

 

So about Change…

 

Teams, especially software engineering teams tend to do tackle obstacles using methodologies that have proven successful previously. Clearly, at times, a proven approach is a valuable thing, but with the challenges of competition, changing technologies, and new marketplaces, we as software engineers need to continually be challenging the status quo.

 This is doubly challenging given the extraordinary efforts just to get things done in the first place using methods that have served us in the past. So, lets look at the reasons people resist change to better understand how to encourage change:

• Time pressures – e.g. imminent delivery dates
• Comfort with known approaches
• Lack of leadership
• Lack of expectation
• Lack of trust
• Organizational alignment
• Fear

Driving innovation and change is paramount to survival in technology markets, so the above are some of the issues we need to address to lead our teams to success. We can go into each of the above in detail, but this is a blog, not a book, so lets focus instead on how to accomplish change. 

In Art of the Start, Guy Kawasaki talks about making meaning in terms of one of the ideals that a start up should have. This is true in selling change to teams as well. People want their lives and work to have meaning. If you can show how the change adds meaning, this is a powerful tool.

 What we need to successfully accomplish significant change:

• Persistence – an unrelenting force that will not abate until change is accomplished
• Vision – a direction for the team to grasp, and believe in through difficult times of change
• Communication – clearly outlining the reasons for change, removing blame from the discussion, and clearly explaining the desired positive outcomes
• Catalysts – people who cause change to happen, through new ideas, through setting an example, or through just being a burr under the saddle. They cause the reaction to start.
• Leadership – people to support the team change, giving time, resources, vision, and anything else required to accomplish the change.

Insights from The Big Moo….

Remarkable is…….

• Remarkable is being unafraid to stand out
• Remarkable is having a fire in your belly and an idea that won’t quit
• Remarkable is telling the truth, always
• Remarkable is knowing that a risky idea might fail, but a boring idea will definitely fail
• Remarkable is failing often and then trying again
• Remarkable is more doing and less planning. More testing and less waiting. More dreaming and less sleeping
• Remarkable is when you stand for something and make it happen and change the world – or your business or your life – along the way
• Remarkable isn’t up to you. Remarkable is in the eye of the customer. If your customer decides something you do is worth remarking on, then, by definition, it’s remarkable.

These thoughts represent my leadership dogma, built from personal experience, readings, and character traits I admire in other leaders.

• Leadership is Personal not Positional – leadership first starts within. Being in a position of authority no more makes someone a leader than putting them behind the wheel of a formula-1 car makes them a race car driver. Leaders are found throughout a company as well as life.
• “When given command, take command” General Norman Schwartzkopf . When put in position of authority, you must rise to the occasion. There is no place for the timid or weak of will.
• Leaders are meant to serve – being a leader should not be primarily for personal gain, but rather to serve those you lead. Think of a pyrimid flipped upside down. The more people you lead, the more people you serve. When I look to hire a manager, it is a leader with the personal skills to serve their people that is top of the list. Serving can come in many forms – it should not conjure up connotations of weakness, but rather strength that comes from working hard to help the team succeed. There is a great book on the concept of Servant Leadership.
• Set and keep and eye on a vision – more than almost anything else, people look to leaders to show them the way. Leaders need to have a clear vision of where the team needs to go, and then tenaciously steer the ship through a thousand minor course corrections toward that destination.
• The Team – leaders build teams from groups of people. Teams pull together in a coordinated effort to achieve a goal. Effective teams develop leadership at all levels and a peer to peer accountability for results. They work hard together, laugh together, pull together.