Skip to Content

Category Archives: Business

Conference presentation: Senior software developer recruiting and community management

Curious about senior recruiting and communities? Here’s a talk I did at Hirepalooza 2015. Here are the Hirepalooza 2015 slides, which might help, given a couple jumps in the video. This is the description from the talk:

Even if you have a limited budget you still need to recruit tech talent. Join Eric Siegfried, CEO of TangoSource as he talks about how to find and hire the most critical technical talent on your team– even when you have close to no budget. From this session you’ll learn how to build and leverage an ecosystem, relate more to senior talent, and raise the level of your team.

 

0 1 Continue Reading →

The Scrum retrospective meeting: an introduction.

Some people underestimate sprint retrospective meetings and think of it as simply the time when a sprint ends and they can move on to what’s coming next week. But in reality, this meeting provides an opportunity for the team to identify relevant action items to improve their performance. This is the moment where the team can meet and examine each other’s performance for the sake of the project. It’s also an opportunity to update and improve the team’s definition of done.

There are many ways to lead a retrospective meeting. I’ll share with you what has worked for us.

At the beginning of each meeting

Make the purpose of the meeting clear for everyone. If this is the team’s first retrospective meeting, it’s important to define how it will work and mention the rules. The Scrum Master (as moderator) should make sure that everyone has their say.

A brief summary…

Refresh everyone’s memories about what happened during the sprint that just ended. Offer a brief summary of the most important events of the ending sprint. You could also merge this part with the next section (the brainstorming part). The team can share their ideas and opinions while the Scrum Master tells them about the most important events that occurred during the last sprint. In this way, they could express their thoughts while remembering the events.

Brainstorming

This is when the team refers to tasks that went well, could have been done better or went simply bad. Those three areas can be called differently depending on your approach, we personally use:

  1. Start doing
  2. Continue doing
  3. Stop doing

 

The areas could be tools and methods, communication, working styles, processes, etc.

In my experience, people can lack the confidence to be straightforward and say what they really think about an issue. The Scrum Master should try to elicit their thoughts and help them express themselves. Tact is important here. You need to choose the right words to avoid being offensive when referring to the way that people do certain things. Being indirect can also help, by talking about the issue and not the person who caused it.

Room for improvement

It is important to have action items for every identified issue. And the Scrum Master should make sure that she follows up on each of those. Some people suggest focusing on only a couple action items per sprint.

Closing the meeting

Here is where the Scrum Master gives a brief summary of what was achieved during the meeting. Thank everyone for their time and energy invested in this important event. They should reflect on the way the meeting was conducted and find ways to improve it if necessary.

I personally believe that leading a retrospective meeting is part psychology and part engineering. You have to know how to work with people, communicate effectively, and manage communication among the team.

We have developed our own tool to manage retrospective meetings (as well as pointing sessions): TangoSource’s Planning Poker. We invite you to use it and tell us if you find it useful, and if you have any suggestions. You can read more about it in this other post from us. Plus, it’s free!

planning-id-01

 

We also offer Scrum project management consulting, shoot us an email at contact@tangosource.com if you want to hear more.

Thanks for reading! Let me know how your experience has been with retro meetings (and any tips or tricks you might have learned) in the comment section below.

F.

1 4 Continue Reading →

The product owner’s job: to say no.

Have you seen a team that doesn’t understand the reason behind developing certain feature? Have you had a sprint review where more than a half of the features are rejected? Or that the team develops a huge feature that doesn’t add any significant value to the product? If you’ve seen this in your project, it might mean that your Product Owner is doing something wrong.

We can consider the Product Owner to be the main stakeholder. She should own the product and determine direction. The reality is that the Product Owner role is different from that of a project manager, since she has the passion, the vision, and, unlike a project manager, has to say no to people. Let me explain.

Saying NO to stakeholders.

On a typical project, the team delivers a certain amount of story points per sprint. But it’s common to see that once stakeholders notice what the team is capable of doing, they start asking for more and more stuff. Imagine that certain project has around ten stakeholders, and each one of them suggests a new idea, which represents, let’s say, two story points. The problem is that the team is only capable of delivering ten story points per sprint, and if we let this situation run out of control, then we will end with an infinite queue of pending work.

The Product Owner is the one in charge of prioritizing the work queue. More than that, he is the one in charge of preventing the creation of that infinite queue of features, and the only way to do it is by saying NO to stakeholders. At least from time to time.

It’s true that the Product Owner must develop a good relationship with the stakeholders, and part of this is helping them decide what should or shouldn’t be part of the product backlog. By having a clear product vision, a well-studied market, and regular interviews with end users, the Product Owner should be able to determine what features are the best for the product.

Saying NO to the current backlog

The business value produced by each feature tells the PO what should be the priority for each story. Let me clarify, when I say value I’m not talking about the size in story points, I talk about the actual ROI of each story.

The Product Owner should be skilled enough to find out the real value of each feature, by studying end-user behavior and market trends. Let me give you an example of that.

“Jim Employee” is part of the marketing department of a graphic design company that sells templates to graphic designers. On a sprint review, Jim proposed to add a small countdown clock right below the daily offer section. The only problem is that his requirement was down the road in the backlog because of the urgent features that the accounting department has requested.

“Mark Product-Owner” decided to support Jim with his idea and he put it at the very beginning of the next sprint. After an (expected) argument with accounting, he stood his ground, and the team developed Jim’s idea.

At the end, that small requirement increased sales, and it wouldn’t have been possible without Mark’s support.

What if one of the stakeholders proposes a simple change to the interface that improves the end product a whole lot? If the stakeholder doesn’t have enough influence and there’s a lot of pending work on the backlog, chances are that the feature could stay in the backlog forever. It is the product owner’s job to support good ideas that have high value.

Saying NO to the Scrum Master.

It is true that the scrum master is the one in charge of making sure that Scrum is followed as intended. However, there is just one person that can say no to the Scrum Master and change a sprint’s path or add features, and that is the Product Owner.

According to Voltaire, “With great power comes great responsibility” and, in this case, that quote applies very well. The Product Owner is the only one that can say no to the Scrum Master, and if she doesn’t use this power wisely the team could end with a useless Scrum implementation.

But, when can a Product Owner interrupt a sprint? There is no rule for this; it depends on the urgency of the requirement. As a rough guideline, I could say that most of the time a sprint can only be interrupted because of the appearance of an urgent bug on the production server. It is the Product Owner and the Scrum Master’s job to exert their judgement and decide when a sprint can be interrupted for the sake of the project’s health. Nonetheless, the Product Owner has the last word.

Saying NO to the team.

It’s the team’s job to think outside-the-box. However if they didn’t have any external boundaries to keep them in check, the product could easily become something different than what the market, users, and the company need and want.

One example of this happened to me when I was Product Owner of a project that started as a small demo to a group of investors. After a few months of work it became a more serious networking application.

On a Sprint Review Meeting, one of the most experienced developers of the team asked me to spend a significant part of the upcoming sprint time on redefining the architecture of the application. He explained to me that the design that we had up to that point didn’t fully support the new requirements, and we had to do it right away.

At that time, we just had one “urgent feature” to develop, so it was easy for me to say yes to that. I wasn’t sure I had made the right decision until some time passed, and the velocity of the team went up. When I asked about what changed, they told me that the new architecture was allowing them to develop things faster.

Later, I received a suggestion from the same developer about moving to a NoSQL database. According to him, that database model offered better compatibility with what the product was becoming. I analyzed the situation, asked for some advice and I decided that it wasn’t a good idea to proceed at that moment with the change. We were far away from launching the product and, even though we were near to the deadline, the improvement on the application’s response time wouldn’t be significant.

In other words, the Product Owner is in charge of making room where the team can experiment with their ideas.

Having a great relationship with everyone.

I’d say that this is the hardest part of the work since this involves a lot of what some people call “soft skills”. It involves leadership, friendliness, persuasion, and more.

The Product Owner must have a good relationship with her team and become the main bearer of the product’s vision. She or he should maintain a good relationship with the Scrum Master since he will help her to mediate difficult situations and will support her with the improvement of the Product Owner’s performance.  Finally, she should maintain positive relationships with the stakeholders. They are her customers, investors, and end-users. Without them, the project wouldn’t be possible.

The Product Owner role is a complex one that needs skills and knowledge in professional communication, user experience, and market research. At TangoSource, we have internal Product Owners who act as the eyes and ears of our customers. They are in charge of interviewing the stakeholders, studying the market trends, and defining the features of the project. Ultimately, they’re responsible for the results at the end of the sprint.

Want to know more about how we run Scrum within the company? Drop me a line or follow me on Twitter, I’ll be glad to strike a conversation.

Thanks for reading!

R.

0 9 Continue Reading →

Open sourcing top down zombie game

We’ve been working with Heather Poon to provide open source art for a top down zombie shooter game. It is covered under the Creative Commons Attribution Share Alike 3.0 license

0 0 Continue Reading →

Knowing when to fold ‘em, and the price of success.

For those of you who happen to look at other parts of our site, like the portfolio, you may have curious about our personal productivity tool, Todo Zen. It’s a great example of a viable product that was too slow to the market to make an impact, derailed by the success of an incompatible business. So what happened, and what can you learn from our experience?

Todo Zen origin

After trying out our first product that was getting limited traction in a small market, we realized it was time to move on. My cofounder, Federico, suggested that we try creating a task management tool, and introduced me to Kanban. That evening, we went to a restaurant, and wireframed most of what would be in the product with torn up napkins.

Problems with launching the product

The Mac App store was coming in a couple months, and we wanted to try to package a web app that we could launch on multiple platforms. This was our first mistake, since we were beholden to a dev with limited availability, who had some slightly exotic knowledge. This added at least three months of delay to the process, and we gave up first mover advantage in the store. I also was a bit perfectionistic about the design, and a redesign and implementation cost us another 3 months. Clearly we went well beyond MVP to get this out the door.

Service business wins out

While all this development was going on, around a year and a half ago we met our first major service customer at a conference where we were demoing Todo Zen, and saw a new business model that could be scaled. Success in the app store seemed like it would be a lightning strike at that point, and I felt like we were competing for a small segment with a lot of devs who are obsessed with productivity too. Faster cash flow also won out, given a couple years at product attempts that had limited traction.

Conclusion

I think the experience was valuable, as it allowed us to learn what’s involved in making product, and it felt like we experienced almost every single one of the pitfalls involved. If we had to do it over again, I would start by choosing a larger market, and leveraging areas where we have an unfair advantage. From the Oracle of Omaha:

In business, I look for economic castles protected by unbreachable ‘moats’.
-Warren Buffett

Buffet is looking for lasting competitive advantages in his investments. Understanding your team strengths, and where it can uniquely exploit the opportunities in front of it, is a recipe for great success. If there’s a large market that has an opening for a different approach, with very few people capable of executing, the odds will be stacked in your favor. According to the Small Business Administration, around half of businesses fail in their first 5 years. My advice? Take every advantage you can get.

0 0 Continue Reading →

Team extension: How we more than doubled in size yearly, while bootstrapped, since 2009.

Team extension (noun):The service category of helping companies scale their staff with remote contractors who integrate into the current business process.

So where did this term come from? Back in 2009, after a few months of working part time on my first software product, my company announced a voluntary layoff program, due to the excess software engineers in the organization. Within a day, I signed up to sign off. With some self funding, I had an 18 month window to try to find a profitable business after I found a technical co-founder.

During that time period, we killed off one product, started a second, and finally found a working business model, by paying attention to how our business was actually performing. So how did we get to 12 people on payroll from just 2 co-founders in a little over 2 years? Here is the story of team extension, the foundation of TangoSource’s growth.

Lessons learned from a rocky start with consulting

After our first product failed, we wanted to lengthen our runway by doing outsourced contract work. TangoSource already had a couple of advantages from having an office in Mexico, namely time zone, and software developers with an understanding US culture. Sometimes things went well, other times we had plenty of room for improvement. There were a couple important commonalities that I noticed in projects that didn’t meet our standards.

1. Outsourcers hate losing face. As Malcolm Gladwell mentions in his book Outliers, many cultures recognize status differential more profoundly than people in the US or Europe do. This often comes to light when an outsourced dev should mention an issue, but instead tries to think his way out of the situation. They spin their wheels trying to solve the issue themselves, whether it was a bad requirement, an architectural error, or a mistake that they should have owed up to a long time ago.

2. Fixed scopes create adversarial situations, instead of building teams. From the Thoughtbot Playbook:

“We don’t do fixed-bid fixed-feature-set proposals. This contract style sets the vendor and client working against each other instead of with each other, right from day one. Instead of discussing how a feature should be built, or what assumptions were wrong, you spend time negotiating about what was meant in a document written a long time ago. But it’s worse than negotiating – it’s retroactively discussing something that no one will remember the same way anyway.”

Nowadays, we offer a free 20 hour trial, that would otherwise be spent making estimates. This is in alignment with Agile Estimation and Planning, one of my favorite PM books, which digs into a strong alternative to running fixed bid projects, by using empirical data for each project to reasonably estimate future performance.

Concept origin

In early 2011, at the Launch conference, I ran into someone who would fundamentally change the way we were doing business. I mentioned my access to tech talent, and that we were doing contract work on the side. After keeping in touch over the course of a few months, we started an engagement with one of Seattle’s premiere Rails consultancies.

What I noticed a couple months in, after nailing down communication, process, and training our developer in unit testing, was the gradual decrease in time commitment from our leadership. This engagement was profitable, and easily maintained, and I realized I had a scalable business model. After some soul searching, we decided to shift to a service model, since we didn’t see anyone doing similar work in the marketplace, and saw a serious need. That initial engagement has been ongoing since then, and we have fostered others like it, thereby allowing us to focus on recruiting and training, while having high utilization.

Team extension benefits

So why did we decide to specialize in a new service category? According to much of The 22Immutable Laws of Marketing, it’s important to be seen as first in the market in some way or another. There’s also a long term strategic benefit to becoming the authority in a category, particularly one that generates value for everyone involved. So what’s in it for our customer?

  • We can scale more cheaply, and pass those savings on to the customer. Because Team extension is a high utilization business, the customer doesn’t have to pay for our marketing efforts, or our down time.
  • We focus on team building with the customer. Instead of arguing over a spec, the customer is with us each step of the way, looking for ways to improve productivity, and everyone benefits.
  • Ongoing engagements engender trust. When developers trust the customer, face saving issues don’t come up as often, and the team is more efficient.
  • We’re able to guarantee developer time. As a project grows, it’s important to make sure it has a stable development engine. Due to ease of forecasting, we can maintain grow with the customer smoothly.

Team extension best practices

There are a lot of choices from the toolbox to run a project. Some tools, such as project management (eg: Pivotal Tracker, or a variety of Kanban SaaS) mean picking a single tool for the project. Other times there are a variety of tools that can be used, and it’s a question of using the most lightweight ones that get the best outcomes. Here are a some of the practices that have helped for Team extension:

1. Pair programming. Pairing helps developers work out more complex code issues, by creating a social environment where two people focus deeply on code, as well as easing knowledge transfer. For Team extension, it has a key benefit of allowing a team to take collective responsibility for rough patches in the software development process, instead of an individual spinning their wheels, trying to figure out a way to avoid losing face. Additionally, two minds mean that it’s less likely for there to be an issue to get stuck on in the first place.

2. Text standups. Having minutes of what people have accomplished, what they’re planning on accomplishing, and where they’re stuck can be helpful for Team extension. First off, sometimes customers can’t always attend a SCRUM standup. Second, some devs may have good written English, but are not easy to understand via voice. This practice has helped avoid a lot of miscommunication.

3. Use a good task tracker. Transparency is key when building teams, possibly more so when certain members are remote. Being able to see what’s going on with a granularity that’s helpful, but not onerous, gives PMs and product owners the chance to help clear roadblocks to productivity.

There’s also a bit of secret sauce that goes into setting up projects, managing software development, and training developers. I’ll probably write a separate Team Extension best practices article sometime in the future.

Wrapping up

If you’d told me 3 years ago if I’d be running a service business, I’d have been incredulous. Once I saw what was happening objectively, with a reality check from mentors, I was able to lead the evolution of an advantage into a working business. If you happen to lucky enough to be able to validate a business model, I suggest you press every advantage available to establish your position in the marketplace.

0 0 Continue Reading →

Finding a technical co-founder: You’re doing it wrong

When you’re trying to create a new product as a non technical person, it might seem easy at first, until you start looking for real technical partners. Either you need to pay more than you can afford, or they simply aren’t interested in what you want. As a potential technical co-founder, there’s often so much work that has to be done before an idea gets validated, it sometimes feels like you’re on your own, with a non technical co-founder just waiting for things to happen.

Creating true partnership is what’s required to if you want to offer your deep gifts to the world. For myself, it took a while to find a real technical partner. Hopefully this post will make your efforts a bit easier.

The incident that made me want to write this article

I was at a tech mixer recently where I was talking to a gent, let’s call him John, who had been looking for a co-founder for months, with no success. His project was technically challenging, leveraging a monetization strategy for a platform that had no track record. John was banging his head against a wall. He didn’t realize the sacrifice that his potential technical co-founders would have to endure for a risky startup. I felt bad for him, and explained most of what I’ve put in this post. I’m hopeful that this effort will help you avoid some of his pain.

A startup is like raising a child

When joining a startup, founders implicitly agree to a multi year commitment to each other. It takes time for ideas to prove out or fail, and there’s a huge opportunity cost. People could take paying gigs instead, or simply do a different startup. The startup is like a baby, that could mature into something great, but there’s a required sunk cost that could be years of work before the magic happens. Because of this, your partner should be someone who you enjoy sharing the journey with.

Technical co-founders early on in a startup really are playing the nurturing role. So much of their time goes into product, whereas it’s sometimes hard to see what a business co-founder brings to the table other than cash. When approaching someone for a possible committed relationship, ideas by themselves are cheap, action is what counts. If you were to approach a potential mate and simply say, “we should get together and have sexy children” that wouldn’t cut it, and neither is a simple business idea.

This doesn’t mean that people shouldn’t form relationships, as successful ones happen all the time. It just means that you have to create the foundations in yourself before approaching someone, expecting a positive outcome

Ways to show value

1. Be authentic. If you want to show that you’d be a good partner, you need to be human and genuinely relate with people, not objectify them by assuming they are there to do things for you. Interact with the WHOLE person by talking with genuine curiousity about their interests and desires.

2. Validate your product idea. If you’re providing business skills for the startup, back it up with action. Take steps towards product market fit, such as getting signed Letters of Intent (LOIs) which show that your product will have revenue on day 1. You could also create a business model canvas, and collect real world data for each section of the canvas.

3. Cocreate an experience. There’s value to be found in most social interactions. Don’t presume an outcome, go with an open mind and a belief that there is some spontaneous positive result that can happen if you have an open mind. You can create with the other person, and meet them where they are to get to a new place. It’s hard to tell if you’ll work well with someone until you actually do so in some way. Startup Weekend is a great shortcut that can help see how people work.

4. Give a gift regardless of expected outcome. In a recent article, LinkedIn co-founder Reid Hoffman talks about “giving helpful help” as a means of nurturing new relationships. To be able to do so, you need to know the other person well enough to figure out how you could help them with a reasonable investment of time. In the past, I’ve pointed people to different books, or made introductions. As long as this feels like a personal gift, you’re golden.

5. If needed, bring cash. Just like the technical co-founder who is putting tons of hours in, you need to have skin in the game. Executing the non-technical parts of your business plan is a must, but often this translates to providing funding for enough runway for V1 and possibly a major pivot afterwards.

Genuinely check for a good fit

Just like dating, it helps to know what you’re looking for if you want to avoid wasting time, and create something wonderful. Have a set of criterion, such as values, skillset, and work ethic, which will help you select on a logical level.

So how do you know if your values are compatible? Here’s a shout out to Tony Wright, who shared some key startup values with me. Here’s a paraphrasing:

  • Passion – How passionate do they need to be about the problem space?
  • Risk tolerance – Are they willing to endure the financial hardships of a startup? Do they want to raise funds ASAP to limit risk or maximize ownership?
  • Motivation – Do they want money? Fame? To serve a particular audience? To solve a problem they’ve been enduring?
  • Target – How big do they want to get? Would they be happy with a lifestyle business, an IPO, or something in between?
  • Appreciating skillsets – Do you value each other’s respective disciplines? If not, over time you may resent your co-founder as being dead weight, which is a recipe for disaster.

A lot of these values are about risk. If you’re serious about the same problem, agree on the financial risks, and are going for the same sized goal, you probably are compatible with respect to risk.

Finally, a major benefit of being genuinely selective is that it projects that you value yourself. Most people want to be with someone that knows their own worth. It also helps to listen to your gut, because you’re deciding on a relationship, not solving a mathematical equation.

Build up your network

It helps to have a solid network of friends, not only to have more candidates, but to lay the groundwork for business partnership. I go over an example of this in my blog post about volunteering for a non-profit, Vittana, which ended up turning into business. In general, what you want is a T shaped network, which is wide and sometimes deep, as a catalyst for great ideas and partnerships.

Wrap up

Just like dating, you need to get out there a lot! Ideally spend time in places that you’d enjoy, regardless of outcome, such as a tech gaming night. Building up a group of friends in the startup community takes time, but like anything worthwhile, the time spent pays off in profound, life changing ways.

0 0 Continue Reading →

Coding for a cause: Benefits and Pitfalls

Does free work sound like a bottomless pit of time expenditure, with no chance of compensation? Have you ever wondered how to do pro bono work in a way that not only improves the world but helps out your bottom line? Our team just released some pro bono work for Vittana, which I think was time well spent. Below you can find out how it came about, why it was worthwhile, and read some lessons learned to improve the odds of success for your next pro bono project.

Discovering the project

When I ran into my friend Kenji at a mixer a couple weeks ago, it seemed like a usual incidence of our paths crossing, given that in one recent week we ran into each other 4 times at various tech events. Little did I know that the project I’m posting about now would be revealed. Kenji mentioned trying to raise awareness for Vittana as a means of making a difference, via a blogger challenge. For those not in the know, Vittana provides microloans to students in the developing world, and donors can choose how funds are distributed, as well as distribute funds each time students pay back their loans.

Over drinks, Kenji and I bounced around a bunch of ideas and eventually we came together with a plan to create a blogger challenge with a leaderboard sorted by tweets and dollars lent through the challenge. It took a bit of back and forth, but eventually we were ready to rock.

Working with Another Team: How we did it.

In order to keep the project from spiraling out of control we:

Defined Scope:I’ve talked with people who have done pro bono work, and one of the worst outcomes is ever expanding project scope, with no end in sight. To prevent this, we established some ground rules to keep it from getting out of hand. By the time that the contest started, we agreed that we would hand over the code, and give maintenance responsibilities to the Vittana team.

Established the Concept:Our first task was to establish the concept before any serious coding began. We wanted to create some background tasks that made Twitter API calls to search for number of retweets associated with a given blog post. To narrow the search down, we suggested using hashtags. A possible side bonus is that we could create a trending topic and create some buzz.

Minimized Reliance on the Vittana Team:To ensure we didn’t have to take a deep dive into their code base, the Vittana team gave us JSON feeds containing all of the necessary fields (including donation totals) for each of the bloggers. Given the nature of the work, we were able to have a quick pile on of a few developers, giving them a change of pace for a couple days, and then allowing them to move on cleanly.

Why did we do this?

First off, I’m always happy to make my friends look good and improve the chances of a successful project. Given that the Vittana team was already slammed, I saw a great way to help out a friend. I was also able to do some good for a cause that I care about personally and professionally. TangoSource trains developers in our locale to increase their odds of professional success after college.

We also have a few developers that we’ve been training and were just about ready for production quality code. I believe that real work is more interesting and effective in training junior developers. This seemed like a good opportunity to expose some guys to a real world project.

Finally, we were presented with a chance to expand our business. Despite being relatively young, Vittana has a strong brand with a lot of awareness, which was a chance for great exposure. The possible value for the TangoSource brand seemed significant. Here’s a screenshot of the link we were given on the contest page:

Cause-Img

I also found out recently that the Vittana team is interested in discussing TangoSource doing paid work. This should not only provide us a means of growing the business, but also help us do good at the same time.

Lessons learned

1. Don’t rely on others to test your code.To a certain extent, we assumed that the other team would test our code on production. We ended up having to do some last minute patching that would have been more efficient if encountered earlier in the development cycle. Initial testing also exposed some places where the interaction design was broken on the admin side that would make further testing difficult, and we had to code out a much more involved administration panel. This was an affirmation of test early, test often, with a realistic scenario.
2. Remember to nail down the environment before writing a line of code.In this case, we assumed that Vittana was using the same database as what we were testing for in our local environment. That mistake was an fast way to waste a couple hours. Also, unit test your code regardless of the scope of the project. We wasted a fair amount of time on regression errors.
3. Whenever possible, try to limit scope in a way that’s win-win.It makes sense for the Vittana team to take ownership of our code. The more complex our product, the more work needed on their side. Also, since this was a new type of initiative, we were able to execute a lean exercise for them without too much investment for either party.
4. Networking is valuable but often in an intangible way.Deeper connections are more useful, but take work to find and cultivate. For me, this means meeting plenty of people to find those that I connect with. Afterwards, there’s the enjoyable investment of staying in touch, which helps create opportunities.
5. Genuine altruism is a great business strategy.You never know what might result from doing good. After starting work, I ran into the some of the Vittana leadership, who mentioned they might need some development help on future projects. This was confirmed in later communication, after they performed some code review.

Final results

With 90 hours of work total, I feel this was a worthwhile way to spend our time, even not including the chances to grow TangoSource’s business. From a purely utilitarian standpoint, this effort will probably pay out regardless. Subscribe to our blog to find out!

Stay tuned

During the course of the blogger challenge, check out Vittana Twitter and the leader board we helped create:
http://www.vittana.org/make-a-difference
Be sure to spread the word to help fund students around the world.

Also, we’re planning on releasing a Rails gem that does the majority of the Twitter heavy lifting, so keep an eye on the TangoSource blog if you want help automating the tracking of tweets.

0 0 Continue Reading →

Finding quality outsourcers, the story of TangoSource

Does your outsourcing experience resemble the image above? A ton of strangers, randomly trying to find work? And after finally choosing someone from the crowd, having to deal with a lack of accountability, poor work product, and lack of passion. I know, I’ve been there, and I’ve learned many lessons. Hopefully my story will help you save time and anguish.

How is all started:

TangoSource’s 1st product was, drumroll, a social network for tango dancers! After the bliss of the first couple of months, I realized that our market wasn’t big enough, so I included ALL social dancers and created DanceHop, an events 2.0 website. I’ve outsourced the design to Yilei Wang and Ruby on Rails development to a local developer, who I’ll call Ahab.

Ahab repeatedly apologized that it was taking him so long, which should have been a red flag. Fast forward, he quit after 3 months of work and gracefully declined equity. This forced me to look at Working with Rails to find a replacement. I settled on an Argentinian developer, Rodrigo. He started coding, and Ahab said I’d found “a diamond in the rough”. Now being smart, I’d engaged a local Seattle Rails guru a couple hours each week for code review to ensure I’d only keep developers that were improving.

A month in with Rodrigo, it became clear he could only code part-time, so I was back looking for help. This resulted in a string of devs, including an Indian developer, Dibya, who delivered but was a bit expensive; a cheaper Indian developer who didn’t deliver; and two more part-time Ukranian developers Dmitry and Igor who eventually also dropped out.

Finding a true partner:

A month after Rodrigo dropped off, I found my co-founder, Federico Ramallo, on Working With Rails. After a long and enjoyable interview with Federico on Skype, I asked if he was open to taking equity to offset some of his compensation. I’d already seen that his life values were compatible with mine, and our personalities jelled together well. He was open to equity, and after a month trial, with my Seattle Rails guru overseeing the process, we started a professional relationship that turned 2 years old as of September 2011.

Federico eventually moved to Colima, and we set up an office/co-working space there, which has been fantastic for recruiting. At that point, any thought of recruiting outside of our realm of influence was gone. We’ve trained up some great devs, found others, and the investment has been paying dividends in terms of output, and company culture. To wrap up, I’ve included some guidelines that I learned through my hiring experience, which I may go into detail in future posts.

Quick tips for finding great outsourced devs:

  1. Discuss values in the interview to see if you’re on compatible paths
  2. Offer a trial period of 1 month, with increasingly large test tasks
  3. Clearly define what meeting your expectations means
  4. Have an outside observer if you aren’t an expert in the field
  5. Run a daily SCRUM standup meeting, for clear lines of communication and personal connection with your team. Have accomplishments since the last meeting submitted in text before the voice meeting.
  6. Give a bit of a benefit of the doubt, but more than a couple days of poor performance or communication and it’s probably time to move on to the next candidate.
0 0 Continue Reading →

SEO keyword research part 2

When you start optimizing for keywords, a few chosen terms will typically be the most that you can focus on at any given time, so it’s super important to be focused on the right terms. In my previous article introducing SEO keyword research I reviewed keyword intent, and how to determine search term value. Now I’ll be going over the process of finding keyword ideas, and determining competition.

Finding keyword ideas

First things first, you’re going to want a plentiful list of keywords to sort through so you can find a few valuable terms to optimize for, as well as low hanging fruit that you can sprinkle into your content. Going back to our original example, helping a friend’s cupcake recipe site, let’s see what kind of terms we can find.

First let’s look at the Google keyword tool’s keyword ideas.

SEO2-Img

For the results above, I clicked “Only show ideas closely related to my search terms”. In this case, I used both “cupcake recipes” and “cupcake recipe” to get more ideas, given I’m using exact match. Looking at the keyword ideas, we can see some of the top searches by clicking on local monthly searches. I choose local typically because it’s often easier to monetize off of US traffic. It looks like the traffic isn’t great for the top related terms. Interestingly the short tail is recipe specific, the slightly longer tail (with more traffic) is more about the quality of the recipe.

Remember to sign in, otherwise you’ll be limited to 100 results. I got 800 results (the max) after signing in, and if I wanted to get more ideas, I could use more narrow terms to find a broader selection of keyword ideas. To save time researching, remember that you can export the results to spreadsheet!

For more resources, here’s a nice survey of keyword generator tools.

I’ve used the Wordtracker trial to good effect myself.

You can also sign up for SemRush, and look at your competitors terms that are driving the most traffic.

Now let’s narrow this down by competition to find out some reasonable targets given a first campaign.

Keyword competition

Now it’s time to plug all of these terms into a spreadsheet based on value (intent x traffic) and determine their short term value.

Short term value = (intent x traffic / competition).

Ways to gauge competion:

  1. Seomoz keyword difficulty tool (first month is free). I’d advise avoiding the terms above 55 for the difficulty number if this is a new site. The keyword difficulty number takes a lot of different factors into account, and is fairly accurate, although if you’re trying to get to a specific spot on the SERP, you need to do your own research.
  2. Average number of root domain links for top few competing pages ranking for the term. Take a look at Open site explorer cupcake recipe results for an example.
  3. Page authority of the top results. It’s a good indicator of quality links with good anchor text, and domain authority factors in a bit here too.
  4. Site authority of the top results. It’s easy for Wikipedia to rank for terms because of its massive authority, but with authoritative links and the right anchor text, you can compete easily.
  5. Average number of links per high ranking site with the chosen term as anchor text.
  6. Number of pages with the term in their title. Put allintitle:”cupcake recipes” into google, and you’ll see that nearly 100K results show up with pages that have “cupcake recipes” in their title. This is a fast and cursory way to see overall keyword competition.

 

Disclaimer: Niches vary in competition. There’s a lot of factors that Google’s algorithm looks at, which requires testing, and a few months for your efforts to propagate, particularly if your site is still in the Google sandbox.

Wrap up

I’ve now shown a few different ways of finding keywords, as well as shown some tools to guess at the difficulty in terms. Of the five methods I mention, it will take some experience to figure out the right mix. If you’re looking to get a very specific SERP spot for a term, you can use a combination of page authority and number of links with anchor text to see how tough the competition is, otherwise I’d advise using a mix of all five methods. Your milage may vary. It’s a question of how you want to spend your time building up the site overall, versus optimizing for specific keywords, and it takes some experience to figure out the right mix.

0 0 Continue Reading →