First Principles

Posted on July 13, 2014 by Mike Rodbell

We all need to start somewhere. Whether its building amazing software products, preparing a great meal, becoming a star athlete, virtuoso musician, what have you. Regardless of your goals, it’s a good idea to pick a good place to start. Start out with a good foundation of whatever your first principles may be and you stand a far better probability of being successful.

Think for a moment about an incredibly impressive musical performance. Doesn’t matter if its classical, jazz, rock, rap, funk, or whatever your pleasure. In all cases, there are a few people who’ve somehow been able to shine. I’ll bet that all have dedicated considerable time to honing their craft, have a good idea of the feelings/sounds/emotions that they want to convey. The timing is sound, dynamics fitting the sentiment, and technique something that you probably don’t even attend to. But they probably spent a lot of time honing their skills. The end result is a product (the music) that pleases the audience.

So, in following this path, I figured it best to not try and invent something new out of the ether. There have been many smart people who’ve come up with ideas well worth stealing (errr, I mean borrowing). As I reflect on this, there’s a lot to be learned and borrowed from the likes of Stephen Covey, Dale Carnegie, Tom Peters, Ram Charan, and tons of others.

When you think about people that have made a mark, whether it be in technology, the arts, public service, athletics, whathaveyou, I’ll bet that they all have one thing in common: they get and leverage their own first principles. Take for a moment, the musician that delivers compelling music. Doesn’t really matter if its rock, jazz, classical, what have you. They have mastered the right combination of pure technique, discipline, and perhaps most importantly, the ability to connect those with the emotional message that they want to convey. Leave any of those out and at best, you may end up with a pleasant (or really unpleasant) mess.

For me, the keys to success include:

• Begin with AN (I hesitate to say THE) end in mind.
• Approach everything with Enthusiasm and Confidence
• Know what you know. Equally importantly, know what you don’t know.
• Learn what you need to know. Keep learning
• Make and live by your commitments. This includes time and quality. Be sure that those commitments are sufficiently complete (don’t skip critical steps; don’t waste time on capricious requirements).
• Don’t waste time on things that aren’t useful (including low value repetition)

Yours could certainly be different, but I’d bet that there’s a pretty healthy intersection between your values and these. A lot of this isn’t unique to agile software development, it applies to many creative processes. Teams that are enthusiastic, committed, with the necessary skills are far more likely to excel. Skip any of these, and you eventually lose to someone else who is doing this. Stick to these principles (could be others) and you stand a greater chance of success.

First off, life within a team is always easier if there’s an agreed view of the high level goals. Those could be delighting customers, saving money, making people healthier, wealthier, wiser, what have you. That can provide a sense of purpose. It needn’t be, nor should be exhaustively prescriptive (for example, that field on the screen must be a specific shade of green with a definitely font and point size). In an agile world, the goals should be expressed at a high level, generally sufficient to guide the work. More importantly, they must be re-evaluated on a regular basis. Every end goal I’ve been associated has its own half-life. Be prepared to adapt.

Attitude is the lubricant of your development machine. The more people approach the work with the right balance of enthusiasm and confidence, the better things will go. Negative sentiments, rancor, or worse become sand dumped into the engine. I’m not advocating for some form of naïve, Pollyanna outlooks. This is a complicated world, things can, and often do go wrong. When teams embrace those changes and attack the problems with a positive outlook, good things are far more likely to occur.

Software development is knowledge work (duh). With that in hand, it’s critical that teams determine and regularly evaluate their perspective on the problem. This includes the requirements, technical architecture, process, and general environment in which they work. Seeking out and addressing the knowledge gaps is of equal importance. None of us are clairvoyant, and are best served by keeping an eye on blind spots. Take pride in your craft and build products that address all requisite “ilities.”

By making commitments that are reasonable and achievable, you can build a culture of accountability and success. The beauty of most agile approaches is that the commitments are broken into achievable pieces. If, for some reason, you miss a commitment, learn from the experience, and get better in future commitments. Get in the habit of making and delivering against your word. It builds confidence in yourself, and trust amongst your stakeholders.

Waste elimination sits at the core of agile. This can include technologies that emphasize concepts like Don’t Repeat Yourself (DRY), getting things right from the onset (don’t pile up technical debt), and sharing information as readily as possible. As a means to ensure that waste is limited, I like the concept of daylight being a great antiseptic.

There’s no doubt that life is going to throw a pretty regular series of curveballs. By figuring out those things that are your core values, your chances of success significantly increase.

What are your first principles?

Advertisement
Posted in Uncategorized | Leave a comment

Apologies to Groucho Marx (it just sounds like something he’d say).

There’s been a good bit of conversation about motivations in business of late. I’ve seen a common thread that is enticing, and advice that I can recall having heard throughout my life. It hasn’t changed a bit, and now that I’ve been around for a bit (and plan to do so for a good bit more!), it still holds true.

Do something you love, believe in, and good things will happen. Go through the motions and you may make a living, and better find some other passions in life. You may find yourself less happy.

The evidence abounds. Some examples:

  • Josh Bersin, from Deloitte, just noted that companies who act with a sense of purpose experience greater optimism (and presumably success) within the organization.
  • Steve Jobs regaled the Stanford grads of 2005 to Do what you love
  • An old friend I bumped into at the gym advised that “If you can find what you love and earn half as much going in, I’ll guarantee you’ll be far wealthier in the long run.”
  • Ry Cooder: talent is one thing, but you’ve got to have desire

So, yes, some of this is anecdotal, but a bit like the line from Alice’s Restaurant. The one that starts if one person sings the song, it’s not much, but before you know it there could be 50 people walking out of the restaurant singing the song. Seems like the value of being driven by a mission has pretty convincing support.

Think for a moment about the beneficial effects of running your life, or your organizations life with a sense of purpose:

  • You have a context in which your actions are framed
  • You and your peers are able to create a common vernacular against which your work may be viewed.
  • You can describe your goals in a tangible, accessible form.

There are all kinds of missions and purposes available. Making the world a better place is certainly admirable, but perhaps a tad ambitious. Exciting customers, removing pain, simplifying lives, improving learning experiences, and connecting people are all possibilities. It also helps if you’re able to pick something that can add value to others.

So, find something you believe in, either as an individual, or as an organization, and (assuming that something adds value), you have a great shot at being successful. Do something with greater purpose, that resonates, and you have a more meaningful context for your actions. That can frame a lot of great behavior.

Posted on April 28, 2014 by Mike Rodbell | Leave a comment

Winning

Posted on April 17, 2014 by Mike Rodbell

What is this winning thing? Charlie Sheen managed to co-opt the term in a profound, yet scary way.

I’ve noticed that we each have our own definition. My take is that it takes on all forms of dimensions. At its best, winning is at the core of why open, capitalistic societies thrive. At its worst, “winning” can be the underpinnings of cultural angst and decay (viva la revolution, anyone?). Or picture tents lined up on wall street. In reality, winning is a combination of things, some great, and some with horrible consequences.

To many, particularly in publicly traded companies, it means that shareholder value has been maximized. The things that contribute to that are embraced. All other things can take a second seat. This can include customer and employee satisfaction, and in general, the impact to society as a whole. Mark Cuban’s piece on this was particularly fascinating. In it, he cautions that the behaviors of these companies to juice their stock through cost cutting may raise stock prices, but at an ever increasing detriment to society as a whole (unemployed people are less productive, and certainly aren’t making economic contributions).

On the flip side, there’s the post from Barbara Corcoran to “Shoot the Dogs Early” where she shares her thoughts about how to ensure that she has the best people in her organization. Her post received a ton of responses, some of which (the minority) defended her as being successful. After all, she’d grown a company and sold it for a pretty significant sum. But it had consequences. She was on to something in that, to build a successful business, you need good people. Her approach seemed a bit rough. She seemed to show particular disdain for the employees who didn’t help her achieve her desired goals, calling them dogs and losers. Seems pretty unfortunate.

So, what is winning? Not so simple. If you start with a recent, popular definition of the word, from Dictionary.com, you get:

“win·ning

  [win-ing]  

noun

1.

the act of a person or thing that wins.

2.

Usually, winnings. something that is won, especially money.

3.

Mining.

a.

any opening by which coal is being or has been extracted.

b.

a bed of coal ready for mining.

adjective

4.

that wins; successful or victorious, as in a contest: the winning team.

5.

charming; engaging; pleasing: a winning child; a winning smile.”

From <http://dictionary.reference.com/browse/winning>

In life, and business, there are many components, which include:

  • Short term victories. These could include securing new business, grabbing market share, creating a market, perhaps meeting near term target financial goals (such as increased revenue, profit margins, etc.)
  • Mid-term victories. These include creating the intangibles that provide the foundation for sustainable, and recurring victories (you decide what these are)
  • Sustained, long term winning. These come from striking the right balance between financial success and building relationships, resources, and capabilities that serve the needs of the organization and its ecosystem over time.

One definition I loved, which was when I was in the early stages of what was becoming an enormously successful startup was a mantra that we were in it to create value to our customers, that would result in value to the company, its employees and shareholders alike. That’s ideal, not always possible. Also, we were incredibly successful in the short & mid-term, but time, the economy eventually caught up, and we, like many in our industry faced some very difficult times with corporate downsizing. That said, I’ve been fortunate to see all range of approaches.

The economy and society don’t always allow for that to continue unchecked. Capitalism is based on a Darwinian component where companies need to adapt, adjust and be their best. My preference is that be done with integrity and empathy for the people involved, which includes customers, employees, and shareholders alike.

What do you think?

Posted in Uncategorized | Tagged , | Leave a comment

Global Software Development — Training the New Team

Posted on February 3, 2014 by Mike Rodbell

training classGetting back to the previous thread about building global teams.

As you assemble the new team, one of the first, and most important activities will be to get the new team ready.

Consider the following:

  • Hire people with the right skills and aptitude (surprise!). Bring in people with a good combination of technical skills, along with communication and interpersonal traits that will help them learn quickly. Smart, engaged team-players who fit your operating model are the most likely to succeed, and build sustainable teams.
  • Focus your training efforts. Take inventory of the work that you’d like the team to start with. Ideally, its something meaningful, but somewhat less time critical than the work your more established teams are doing.
  • Build a strong foundation. Think a bit about what you’d like the team to be doing further along, once the initial tasking has completed.
  • Plan activities. Based on the upcoming assignments, identify the major gaps that need to be filled to get the team to the point where they are able to contribute on the initial tasks (presumably learning on their own, and knowing where to get answers).
  • Identify the sources of training. Some will be written, some will require interactions with longer term employees.
  • Seed the team. If you’ve taken the hiring path I suggested in my earlier post, you should have been able to get more seasoned, technical leads on board first. These people will become a valuable bridge. Help them become effective as quickly as possible.

None of this should be a surprise. As you plan and move forward in training the team, concentrate on building productive and strong work and social relationships among team members in the various locations. As the team gets to know one another, they will become more comfortable asking questions and sharing information. This will pay huge dividends. Your goal will be to establish a supportive, and collaborative relationship across all groups. When you’re able to do this, progress will come at a fast pace.

I view this process as coming in three general stages, preparation, familiarization, and ramping productive work. Lets take a look at each of these phases.

While you’re busy recruiting, think about what will help the new team members become productive. Take inventory of documentation, build catalogs/directories of key pieces of information. This can include pointers to tooling, source code, test resources, and a directory of who’s who. Consider having some of your key leaders or senior members of the technical staff prepare materials to present to the team. In some cases, recorded sessions and tutorials may be helpful. Also, don’t underestimate the value of budgeting for travel. You may want to solicit support for having team members travel to spend time with one another.

Once the new employees start to arrive, you’ll want to move quickly to familiarize them with your products, services, and the work that you’ve outlined for them. Get people together. Have your business leads provide overviews of how your products and services are used by customers. Have your tech leads walk through the system architecture, and help the team understand the working environment and tools. Have your project leads or directors provide an introduction to how projects are managed. This can include overall process guidance, pointers to tools, and an open Q&A session. You’ll want the team to be ready to interact and collaborate in a transparent & consistent manner. You’re also likely to be training the trainers. There may be other team members who have yet to arrive. The more that you can train their future office mates, the easier things will be in the longer term.

As quickly as you can, get the new team members working on active projects. In many cases, it can be helpful to engage the new team members in sorting out defects and resolving issues in areas of the system. This type of work is a good catalyst for learning the environment, tooling, and application. Assuming that the issues are reasonably easy to reproduce and isolate, defect remediation work helps provide context for those starting to learn the new system. Outside of defect fixing, it may also be useful to concentrate on small enhancements to the product. In general, find work that can be mastered in a shorter period of time, and that gives the new team members good opportunities to contribute and learn.

In the past, I’ve also found that it can be helpful to build out an inventory of key skills and develop a dashboard that can help visualize the coverage of knowledge that you’d like the team to obtain. If you decide to monitor their progress in skills acquisition, also be prepared to adjust your goals, as they are likely to change as the product and competitive environment will evolve in tandem with your team.

These phases of your project can be both interesting and challenging. They provide a great opportunity for everyone, including the legacy employees to learn, and expand their capabilities. Pay attention, and ensure that people are sharing information, and good things can happen.

Posted in Change and Behavior, Distributed Teams, management, Uncategorized | Tagged , , , , | 1 Comment

Getting the most out of your team

Posted on January 28, 2014 by Mike Rodbell

pot of gold. jpegI recently saw some interesting discussions and posts regarding team velocity, metrics, and how to get the most out of a technology team. The original question was about how to increase a team’s velocity. The conversation was interesting & I noticed that people seemed to have somewhat differing takes on how to measure success. Not surprising, since we all have our own perspective and experiences. So, this is my take.

Every team is in search of its own pot of gold (success). The specific terms may be different, but in the end, they all live and die by the value they provide to the parent organization. I recall asking a work associate once what metrics he valued (thinking that we should look at the details). His response was that revenue was his primary concern. My bet is that in almost every organization, you’ll find something similar. It could be profits, growth, or other accomplishments that a good product or service can create.

By taking the perspective that the value is related to the end result, perhaps its best to answer the following questions when considering how well your team (and for that matter, the broader organization) are performing:

  • Why? Do your efforts have a discernible and hopefully high value outcome? Building perfect, high quality, useless software is still useless. Are you providing something that makes a positive difference? That difference will probably need to be measured against both the present status-quo and what competitors are building.
  • What? The things you are building should be well aligned with the base rationale.
  • How? Are you approaching the problems in the best way possible? Are the tools, architecture, and skill levels where they should be? Are you being clear about the measures of quality and completeness as you develop the product. If using agile, is your definition of done appropriate? Are people spending their energy on adding value and minimizing waste?
  • Who? Are your people right for the job? Do they have the right training? Can they communicate with one another? Are they enthused about the mission (don’t underestimate the value of belief!)?

Not surprisingly, there are several dimensions to success. If you’re really lucky, some of these fall into your lap. Odds are, that you’ll need to attend to all of these. So, what to do?

In short, invest your time wisely. Understand where your efforts are going to be the most fruitful. That will vary. There’s an argument in the StrengthsQuest philsophy that advocates for not only striving to fix problems, but perhaps more importantly, amplifying one’s (or one’s team’s) strengths.

  • build a strong rapport with your team. when you start, as you work, any time you get a chance. Failing to do so will limit their output.
  • identify and share your value proposition with the team. Make sure that you and they both “get-it” If they’re having difficulties getting on the same page, figure it out & negotiate common terms.
  • Be excellent and demand it of your team. Make sure that they are requiring the same of themselves. Most people will. There’s always more to be gained by a job well-done.
  • Maintain balance and transparency. One of the most painful problems I’ve seen (this is getting back to my first point) is energy spent on the wrong things.

There are obviously choices that you’ll want to make. Focus on the areas that will give you and your team the greatest returns. Once done there, find the next batch of opportunities. They never end. You just need to know where to look.

Posted in Group Dynamics, Innovation, management, Metrics, morale, Product Management, software development, Uncategorized | Tagged , , , , , | Leave a comment

Global Software Development — Assembling Your Team

Posted on January 25, 2014 by Mike Rodbell

OLYMPUS DIGITAL CAMERAContinuing the discussion on Establishing Distributed Teams.

Now that you’ve decided to build out a new team, presumably far away, there are several decisions that you’ll want to make. These include, but aren’t limited to:

  • Decide on your staffing model. Direct employees or contract.
  • Pick a location. No matter where you decide to go, there will a different mix of factors. I’ll explore that in a bit.
  • lots of other details (where the devil can also reside).

Your decisions will have a profound impact on your success . So lets start with structural model (contract vs. own and operate) and location.

One of the first decisions you may need to make is the general governance of the team. There are places for both general types of organization, and the direction you choose to go should be based on what you believe fits best for your organization. For example, take a look at the following:

Relationship Pros Cons
Employees
  • More control, influence over team activities. May have positive legal consequence related to Intellectual property.
  • If you plan on long term growth in the new location, you can gain a foothold and develop a positive reputation that will pay dividends in subsequent recruiting activities.
  • If you’re just getting started in a new location, there may be significant legal and administrative issues with establishing a presence in a new country.
  • If you already have an effective presence, these barriers shouldn’t be profound
Contractors
  •  You can deal with organizations who already have the infrastructure (facilities, HR, finance, IT, etc.) that will be needed to  get the team moving quickly.
  • Assuming that you pick a good vendor, you can leverage their insights into the local economy, culture, and practices that best serve how to work remotely with their teams.
  •  You will cede some control. While each relationship is different, the contractor/vendor relationship is one in which your vendor will be beholden not only to you, but to other clients. Be certain that they are incented to act in your best interests.
  • Along with that loss of control, there may be extreme cases in which your whole team can be purchased (I’ve seen this one), which can lead to a pretty abrupt cessation of work.

As you can see, there are different models that you may want to consider.

In very general terms, if you have tighter resources and don’t wish to go “all-in” to setting up shop in another country, take a good look at an offshore contracting partner. There are several high quality organizations. There may also be differences in their operating models. Some may invite you to hand pick all staff and treat the assigned team as your own, while others may prefer to align themselves more to a project model in which they take the lion’s share of personnel management. Each of those also will come with their pros and cons. Regardless, you will also be best served by checking around and getting references from people who you know well.

If, on the other hand, your organization has the resources and longer term commitment to setup your own shop, then the employee organization may be a better fit. I’ve seen both models work, and for that matter, both models struggle. Pick a direction that you and your organization find most comfortable.

The other interesting dimension to consider is the actual location of the offshore (or near shore) team. There are a bunch of things to consider here as well, which include:

  • Language. Its generally a good idea to work with people with whom you and your team are able to communicate with in the same language. (so, call me Mr. Obvious) For my past teams, we’d had a stipulation that all team members (regardless of location) be fluent in English, and if not, training would be provided.
  • Prevailing laws. Be careful about things like intellectual property, customs, etc. You could find yourself with surprises. Its a good idea to consult with people who understand the nuances of dealing with the local customs.
  • Cultural fit. The world is a fascinating place and people tend to have different ways of interacting. Some cultures may fit well with one another, others not so much. I’d suggest doing some amount of introspection into your organization’s culture and style and be certain that those you’re working with are a good fit.
  • Political climate. While this can change, its good to be aware of what you may face as major disruptions could have an impact.
  • Time zones. If you’re going a long distance (for example, west coast of US to India), be prepared for folks on both sides to need to be flexible about their work (and sleep) schedules.
  • Talent Supply. Some countries have a greater supply of talent than others. This will impact the quality of work and speed at which you are able to bring people on-board.
  • Local economics. Don’t let yourself get fooled into a “great deal” unless it passes a sniff test. If you find that you’re being offered rates significantly beneath the local range, you’re likely to either get subpar talent, or face severe retention/inflationary issues. It generally takes a fair amount of investment to get people fully up to speed, so be careful with this.

Your goal with all of this should be to select the fit that best suits your organization. There isn’t a single answer that will fit everyone’s needs, so plan on spending some time giving these matters some thought.

Also, note that these topics hit the top surface of the decision process. Each situation will come with its own nuances and interactions. For example, some countries will present a good environment to setup your own presence, while others may be better accessed through an outside partner.

Keep an eye on the highlights, spend your time wisely, and consider investing in help from people who understand the details of running organizations in the places you choose (or are choosing).  Your organization will be the beneficiary of the decisions you make, good or bad (or just middling).

Posted in Distributed Teams, management, software development, Uncategorized | Tagged , , , | 1 Comment

Global Software Development – Identifying New Team Structure and Onboarding Strategy

Posted on January 23, 2014 by Mike Rodbell
Lots of empty boxes!

Lots of empty boxes!

Continuing the topic of how to build global teams.

Much like the earlier process discussions, when you’re going to be building a new team, whether down the hall, or across the globe, there are going to be an assortment of common sense principals that you’ll want to follow. When you add distance to the equation, the importance of getting the right people with the right skills becomes even more critical. Get the right people, and great things can happen. Get the wrong people and you can find yourself spending time.

When you start, you’ll probably find yourself with a significant number of empty boxes to fill. Assuming that you’ve done a good job with your initial modeling and mission of the new team, this shouldn’t be rocket science (for that matter, none of this should be!). What you will want to do is attack the problem in a methodical fashion, while understanding that there may be several surprises awaiting.

When you start building out your team, there are a number of things to think about, which include:

  • How quickly you need for them to be providing significant contributions. If there are acute needs, you’ll want to slant your focus to getting folks with some specific skills. Be careful, though, if they’re too narrow in focus, you could find yourself with training or personnel issues when those great new people stumble in meeting your long term goal.
  • Create a local brand when recruiting. This is going to be a sales and marketing effort, not often a trip to a supermarket where you get to pick your favorite brands of engineer (unless you are extremely fortunate). Build the brand, build a local reputation, and recruiting will likely be more successful.
  • If you’re lucky, you may find teams who have recently completed work. One of the pitfalls (which could be to your advantage) is that things can change, sometimes leaving talented groups of people on the beach. These can be great opportunities to get a team who’ve already done the storming, norming, and forming, and will be ready to spend their energy on your project rather than team building. Don’t underestimate team gel.
  • If you can afford it, start with a more senior team, and definitely start with a good lead (or leads) who have the technical and managerial expertise to attract and retain the needed talent. These are people you’ll want to be able to depend on as your partners. They should be tuned into the local culture, and comfortable sharing their ideas and insights as you move forward. Your relationship with them is vital. The ideal case is one where they are good at what they know, are comfortable sharing what they don’t, and tenacious in filling the gaps.
  • Plan on the senior people being able to spend considerable time on recruiting.
  • Hire smart people who enjoy learning. If you’re looking for a quick fix alone, you may be better served by seeking out contractors who want to do project work. Also, beware of hiring only people with specific skills or buzzwords on their resume. Focus also on intellectual and interpersonal skills. Get people who have positive outlooks, high learning capacity, and get along with one another, and you have a higher probability of success.
  • As you build out the leadership team, start bringing in more junior staff as appropriate. That will serve two purposes: 1. the leads may want someone to mentor, and 2. you will be able to align the spend rate with your budget and goals.
  • Plan on taking time to get people up to speed, and intersperse those activities with investments in teleconferences, preparation, and travel.  If you can swing it, get people together with one another as early in the process as possible. Good social relationships can pay huge dividends!

In short, build your team with the right leadership, and vision. Prepare yourself to build a strong base, and ensure that you’re building the right match to your longer term goals. Get people that can fit with the mission, processes, and adapt as your world will inevitably change. I have a strong bias towards building teams and organizations that value one another and leverage a high amount of interconnectedness. Check out this TED talk for a great argument for cooperation and collaboration. In the long run, you, and your organization will be best served by a learning, connected, and collaborative team, no matter where they sit.

Posted in Distributed Teams, Group Dynamics, Uncategorized | Tagged , , , , , | 3 Comments

Global Software Development — Modeling Your Transition

Posted on January 19, 2014 by Mike Rodbell

Another chapter in the thread I started a while back….
transition modelling

As you start to enter into the process of moving work to new locations, there’s plenty to consider. I’ve found that its helpful to build out a model of the transition that provides a general sense of direction to set expectations and hopefully allow you to align resources with the desired path. But, as this post indicates, sometimes you can overthink things. Be prepared for reality to be different from your plan. Some of the advice in the referenced article is particularly sound: “All creative people arrive at greatness by the same system: trial and error. Prototype and test. Just like the kindergartners.” You will probably skin your knees from time to time. Plan on getting up and persevering. This is not a simple process, you probably have a lot of people involved, so the opportunities for mis-steps abound.

So, while I’d recommend that you pull together a plan, don’t kill yourself, things will almost always change. As much as you’d like, the chances of your transition resembling a great symphony are probably somewhere between slim and none. That said, you will want to get a good idea of how much the transitions will cost, how quickly you can get the teams up to the desired speed and the amount of disruption that the changes could introduce into your process. On top of all of these warnings, its vitally important to set and monitor interim goals. (I’m a big advocate of agile/lean processes — this is another opportunity to stay nimble). As you work your way through the transitions, set and track goals. These help the team focus on actionable, real objectives.

There are several major aspects to your model. My preference is to build out an initial set of assumptions, and then develop metrics that can be used to describe how you expect your progress to look at. My favorites were cost and relative productivity. These helped us describe the project in material, return on investment language. When assessing the project from a broad perspective (as executives do and should do), these abstractions are very helpful.

Some things to contemplate when building your model include

  • Expertise already on hand and available. You’ll need to tap these folks both to keep the current work moving forward, and very likely to help recruit, mentor, and counsel the new teams as they come up to speed.
  • The skill sets and corresponding levels of seniority of the people you’re adding. This will drive two factors: cost, and acquisition time.
  • The amount of time and energy required to find the people you want to add to the team. You can characterize this in terms of reduced capacity among your current team members.
  • The speed at which you can locate, sell, recruit, and get the new people to join your team. When coming up with this, its best to find actuals that offer a reasonable comparison to your recruitment activities. While recruiting, you need to understand the full pipeline, much like any other sales and marketing activity. You’ll need to build a pipeline, select good candidates, negotiate with them, and for those selected, wait for them to be on-board. Its also a good idea to think a little bit about fall out that can occur when recruiting any significant number of people. Some may accept and not show up. And some may show up and one or both of you learn that its a bad fit.
  • The rate at which the new team members become productive. It almost all cases, they are going to have to learn some new concepts, and if you are asking them to pick up a complex product or industry, that time can grow. Be realistic, this data will help you understand what the new team may be capable of going forward.

Once you’ve collected this information and built it out in some time sequence (I liked to capture that info on a month over month basis), you can build curves that show your spend and delivery rates. With that, you can have a meaningful conversation with your stakeholders, look at alternatives (in some cases, additional funding can help, in others, you may just be wasting money). I’ve seen too many cases of cost side accounting killing the goose (your revenue stream). Unhappy customers are expensive. Former customers even moreso.

Posted in Distributed Teams, management | Tagged , , , , | 2 Comments

Global Software Development — Aligning Team Roles

Posted on January 10, 2014 by Mike Rodbell

silly danceContinuing the thread started here.

As you consider distributing your workforce, whether as a realignment or addition, you will want to determine how the roles of the different groups will relate to one another. Over the years, I’ve seen several models proposed. With enough thought, the right people, and processes, anything can work. Some patterns are just easier to handle than others. Regardless, you are preparing to set teams up that will need to dance with one another. Those dances work best when against the same sheet of music.

Lets first take a look at a few options with development teams. Some of the major themes  include:

  • Separate the work to allow each team (here, there, everywhere) to completely own a particular part of the system problem. In this scenario, each team should include program, product, development and quality assurance. This can work well assuming all of the teams have the requisite expertise and that there are the right communication channels to align remote teams’ work with the broader portfolio and mission. Your big risk in this case is having remote teams go off track. If your team (like many) is committed to lean/agile practices, this may be your best option.
  • Follow the Sun — this one’s been popular in cases where the teams are pretty far apart from one another (think US/India as a key example). One of the more popular cases of this scenario is to have the stateside engineers developing software during their day, and the Indian teams doing the test work during their days (as the US engineers rest). An upside of this is that you can establish a flow & maintain an effective work cadence. A major concern with this is that you leave yourself open for miscommunication & confusion. Any missing information in the exchange can pretty quickly lead to a wasted day (or more).
  • Split work differently — have remote team handle more junior tasks. There’s often a mind-set that the legacy team knows best and should continue to define and direct your product’s architecture. Initially, this may make sense, however over the longer haul, I think that you’ll face two general types of problems. First, the remote team won’t take on the degree of insight and ownership that you may need to build the best quality product. Similarly, by building your team in this fashion, you expose yourself to more communications problems. What seems like a great idea to an architect can pretty easily turn into a mess if not properly understood nor finessed. If you’re dealing with significant distances (time zones can be a killer here!), these problems will recur.

You’ll find that there are many options, and you need to pick the ones that best suit your needs.  My personal preference is to split the work so that the remote teams can have as much autonomy as possible. The cleaner the interfaces & communications amongst teams, the easier life can be. That may be impractical in the early stages (the new team generally has a lot to learn), so you may want to consider staging a transition to whatever your end game may be. Also, don’t discount the value of travel and face time. When people get to know one another, and establish strong personal relationships, life is considerably easier.

Posted in Distributed Teams, Group Dynamics, management, software development, Uncategorized | Tagged , , , , , | 2 Comments

Global Software Development — Working with Legacy Teams

Posted on January 8, 2014 by Mike Rodbell

IMG_0114Continuing from the thread I started a while back. There are several things to consider. The teams that got you to this point are going to have a reaction to adding staff in different locations. For some, it may feel a bit like they are on a roller coaster ride. Could be anywhere from exciting to gut-wrenching.

Or perhaps the following may be a better visual. Whether or not (and when) you choose to discuss the topic, there are elephants in your room. You’re considering changes. There are consequences, and odds are pretty good that you have a bunch of very bright people who will have a reaction.

elephant-room11

Assuming that you’re venturing into a global organization from an existing team, there are inevitable questions.  As a leader in the organization, you have two general choices, one is to not bring it up with the team, the other is have a more candid conversation. Depending on where you’re taking this, either are worth considering (I have my bias, but its really up to you).

Thinking back to some of the observations when I started with this series, one has to be aware that people are going to have a series of reactions to any form of change, some will be positive reactions, some fueled by uncertainty. Regardless of how you envision your approach, I think its wise to minimally understand how your existing team is going to react to adding new team members in a different location This could be anywhere, another building, another town, state, province, or country all-together. Any time you change the team, people will have questions.

I think that this article by Jack Welch captures many of my sentiments about how one communicates with people. In particular, check out points 1 through 3. All of them emphasize trust, communication and follow up. Short story is that its much easier to work with people with whom you have a solid rapport than not. I’ve found that I do better with an open rather than closed book, and above all be honest. I recall a clever former coworker of mine quipping that he wasn’t smart enough to lie. Way too much to remember. I don’t know that many (hopefully any) people are smart enough to get away with lies for very long. Also, secrets are awfully difficult to keep, particularly when you’re probably looking into something that will undoubtedly require coordination amongst several people.

So here are some thoughts:

  • If you have no (or very little) concern for how your legacy team feels about things, or their continued support, you may be able to get away with not sharing any information. Beware of this. Even if they all become irritated and leave on their own volition, you will be developing a reputation as an manager/employer with no allegiance nor loyalty to your employees. In high supply times, you’ll probably survive this, although it may be difficult to sustain in the long run. Your new teams may also see this and develop a negative outlook.
  • There may be things that you’re ready to discuss, others perhaps not so much so. Be sure that you have reasonable and credible answers to the questions that your team will have. If you don’t answer them, they will, and their answers are likely to have more negative consequences. There’s not much point in trying to stifle your team’s imagination!

More than likely, you are going to need the help of the people with whom you’ve worked to the point of the transition. My preference is to be honest with them, hear there concerns, and share constructive thoughts that they may have. You will likely hear a range of reactions. As you best can, work with the team to consider the positive aspects of the change and understand the risks. I’d be careful about making commitments that you can’t deliver (statements like “don’t worry, you have a job for life”). People probably won’t believe you, and your credibility will suffer.

So, once you know enough to share (I’d be careful to share only info that has some credibility — lots of alternatives may cross the management team’s mind early in the process), let them know what you can and what you’re considering, and if they voice concerns that aren’t fully founded, let them know that things are still in flux and keep them informed as you work through the process. I’ve learned from past experience that plans and reality don’t always align. Be careful to speak confidently when you are able, and not waste energy on those things that have yet to evolve (and aren’t apparent).

More importantly, you are probably (almost definitely) going to want/need to have your current team help manage the process. More than likely (almost definitely), these are the people who know your products and directions. You will want their help.

Posted in Uncategorized | 1 Comment