Offshore Outsourcing — is it for You?

I put together this short article to help answer a question many small software development companies and startups are faced with:“Should we continue (start) software development locally or consider expanding (moving, starting) offshore?”.

This article includes simple rules I typically use with my clients to help them reach an answer. The rules here do not cover all situations, but nevertheless can provide a company with an initial direction. Let’s dig in.

Here are several major scenarios when going offshore is beneficial for small software companies.

• Team Expansion. Company has senior technical, process, and product resources onshore and expanding offshore to complement the local team

• Unique Expertise. Company needs unique expertise that cannot be easily found locally but are available through an offshore vendor. The examples of expertise include specific technologies or domain knowledge.

• Previously Done Business. Company is expanding and company principals bring in an offshore vendor that they have done business together with in the past and completely trust.

• Prototype Development. Company needs to develop a prototype of a product or MVP (Minimal Viable Product) where delivery quality requirements are secondary (when starting on this path be prepared to rewrite the product in the future).

If at least one of the scenarios above matches your situation — then the offshore option could be beneficial assuming it is organized and managed efficiently.

If not — it may not be such a good fit. In other words, if you are a 2-person startup planning next Facebook and have decided to go with the cheapest offshore vendor based on a marketing email — think twice!

A word of caution. Even if you use the not expensive offshore vendor, you may still end up paying more than you would pay for a full scale local team. This can happen if key expertise is missing or efficient inter-team processes are not established. If you going offshore route — plan well!

Hope this helps

P.S. I intentionally kept the article short, feel free to comment or reach out to me directly if you interested in more details on the subject.

P.P.S. This article covers specifically Offshore Software Development for small companies. Outsourcing Software Testing, System Administration, Support, or Dev Ops is not in scope of this article.

About Author:

Alex Apollonsky has over 20 years of technical leadership experience in software industry. Throughout his career Alex served as CTO, VP Engineering, Architect, Technical Lead, and Technology Consultant across multiple companies and projects, holds several US patents, certified Project Manager and Scrum Master.

Attributions:

photo used courtesy of Patrick under Creative Commons License

I’d like to thank Dimitry Apollonsky for constructive criticism and help with the article preparation.

Ideas Prioritization with your Team: Agile Approach

Imagine you have a list of ideas you and your team came up with. Now you need to pick one. Or prioritize them. How would you go about doing it? The technique described below will help save you time.

The technique is very simple and based on the agile routine called "Prioritization Poker". It is designed to, well, make prioritization of any ideas by a group of people as time-efficient and emotion-free as possible.

To throw around some numbers: once the technique is mastered, it will take less than 10 minutes for a group of 5 people to prioritize a list of 10 ideas. Impressive compared to hours spent pointing fingers!

Let's dive right in.

What do you need to start:

1. Your team in a room with no-interruptions
2. A list of ideas, features, design decisions, or other line items you will be prioritizing (we will be calling them ideas going forward)
3. A set of large stickers or index cards
4. Markers
5. A surface (wall, whiteboard, large table) where you can arrange the stickers or index cards
6. Pens & paper for the team members to vote

Steps to follow:

1. Write the ideas you need to prioritize on stickers or index cards. Write a unique number at the corner of each card.

2. Put the cards or stickers on a surface (whiteboard, table) arranged at the top next to each other in random order. 

3. Review each of the written ideas with the team to ensure everybody is prioritizing the same ideas!

4. Ask each person to vote - to write down a number  (remember that unique number at the corner of each card?) of an idea they think has lowest priority. Ask participants not to show or share what they wrote. 

5. Ask everyone to hand you the written numbers. The Idea mentioned more than once must be moved to the bottom of the surface.


6. Repeat steps 4 & 5 until ideas are prioritized. On each iteration only ideas remaining at the top are participating in the voting. Also on each iteration the ideas voted down are moved above idea voted down in previous iteration.     

That's pretty much it. 

The technique works best if the number of people participating in voting is greater than number of ideas to prioritize. If it is not the case you might find situation (especially on first iteration) where none of the ideas voted down by more than one person.

If such situation occurred you have two choices.

Option 1: If the number of people participating is less than number of ideas needed prioritization, just move all voted down ideas to the bottom.

Option 2: If the number of people participating is comparable to number of ideas needed prioritization then your team is not ready to make the decision. You can either take more time discussing ideas with the team, or make executive decision.

Happy Prioritizing!

About Author:

Alex Apollonsky has over 20 years of technical leadership experience in software industry. Throughout his career Alex served as CTO, Architect, Technical Lead, and Technical Manager across multiple companies and projects, was awarded several US patents, certified Project Manager and Scrum Master. 

8 Practical Tips for Technical Team Leadership

This is the first article in the series "CTO Tips From the Trenches". The article is based on my personal experience as CTO, Manager, and Team Lead and focused on selected practical aspects of team leadership. I included tips I used most (prioritization poker anyone?). 

Most of the tips here are pretty obvious and common sense-based, do not expect anything you would not come up with yourself. And yet formalizing and following a few simple rules included here can make things… more efficient.

Let's dive in.

Tip #1: Before you start hiring - take a pause... and plan

How many times have you hired a developer because your team is shorthanded, realizing later there is not enough work for his or her skill set? Or brought in somebody just because he or she was recommended and available? 



Here's a lesson I learned. Before putting together a new job profile - pause, ask yourself the following questions, write down the answers:

• what is the team's goals? (what do you want the team to achieve within a year)
• what positions and skills are necessary to achieve the goals?
• what position shall I fill first? (fill Senior positions first!)

Once you formulated the answers you can start writing job profiles - you now have a vision you understand and can explain to your peers and management.

Tip #2: Be super-selective during interviews.

After screening hundreds of candidates and interviewing tens of them it is easy to settle on under-performing candidates hoping he or she will pick up. Don't (unless it is your intention to hire lesser experienced resource). 

As painful and time consuming as it is - keep interviewing until you and your team feel right about the person. The extra time and effort you spent will pay off with dividends.

Tip #3: Fill Senior positions first.

Something I mentioned already, cannot emphasize it enough - fill senior positions first. Otherwise you might find yourself in situation of micro-managing junior resources with nobody to delegate to. 

Tip #4: Trust your team with decisions

It is extremely important for a team make their own decisions as opposed to accepting somebody else's. Why? Decision ownership. If the decision is made by the team - team owns it and will do everything to achieve the decision objective. Therefore - trust your team with decisions, but...

Tip #5: Put structure around team decision making

Making team decisions takes time, usually more time than management decisions. To speed things up - put structure around the process. 

Have a standing weekly (or whatever frequency makes sense) "technical decisions meeting" with your team. Go through a backlog of problems, prioritize them, identify constraints, start discussing and documenting solutions. 

Tip #6: Keep the Final Say

Although it sounds like contradiction to #4, it is not. It could be situations where team is divided over the decision or do not take into account certain important constraints. 

In such case be ready to take over, providing arguments to the team regarding your choice. Ensure it is known ahead of time that you have final say (and are not afraid to use it !). 

Word of caution: exercise this prerogative only when there is no other choice, otherwise you are risking undercutting the team self-confidence.

Tip #7. Work on team culture

Whether you managing a team or department - work on team culture. Making people feel they are part of unique team identity will increase team performance and help to attract and retain talents. 

Tip #8. Use common sense!!!

It is easy to follow well known methodologies and processes, however at the end of the day none of them will cover 100% of situations. If you not sure what choice to make between several options - common sense is your best friend!

Next: Ideas Prioritization with your Team: Agile Approach

About Author:

Alex Apollonsky has over 20 years of technical leadership experience in software industry. Throughout his career Alex served as CTO, Architect, Technical Lead, and Technical Manager across multiple companies and projects, was awarded several US patents, certified Project Manager and Scrum Master. 

Attributions:

photo used courtesy of Rilee Yandt under Creative Commons License
photo used courtesy of Paul Inkles under Creative Commons License
photo used courtesy of Joel Telling under Creative Commons License
photo used courtesy of richevenhouse under Creative Commons License
photo used courtesy of Daryl I under Creative Commons License