Skip to Content

Category Archives: Business

Being a leader as an engineer

Have you heard the story about the two engineers and the manager who found a Genie lamp? This manager and his team were looking for a laptop with crucial information for delivering an app. While searching their storage room, they stumbled into an old oil lamp that would look cool in the office, so they decided to clean it. After a couple of rubs, a Genie comes out.

The Genie told the three he will grant one wish to each one of them, so the first engineer is quick to say: “I want to be in the Bahamas, living in my dream home and owning a yacht” Puff! He is gone. The second engineer screams: “I’m next! I want to be in Hawaii with my husband and a bottomless margarita.” Puff! Gone.

The Genie then turns to the manager and say “Your turn.” so the manager, without skipping a beat replies “I want them back after lunch for the deployment.”

Have you ever encountered a leader like that in your career? Or perhaps you are already a leader, and while reading the story, you were already worrying about what was going to happen to the delivery.

The approach of leadership the manager of the story took is not popular or conventional, but it’s aligned with one definition of “lead” from the Merriam-Webster dictionary, that is: “to guide on a way especially by going in advance” (Merriam-Webster)(1). Leading can be a controversial topic with different approaches and various outcomes.

 

In November, Tango, through Develop.us, led a panel at Yelp’s offices in San Francisco, with the intention of talking about this topic of leadership specifically as engineers and different approaches from 3 different perspectives.

You can watch the panel in this video:

 

Virginia Tan (Engineering Manager) and Steve Workman (Customer Growth and Engineering Manager) represented Yelp, Jason Monberg (CEO) was there for Presence, and Eric Siegfried (CEO) moderated the talk and gave shared his experience with Tango.

 

Leadership in engineering

First, we need to establish what leadership looks like as an engineer, and during her participation, Virginia described it like this:

“Leadership isn’t necessarily having a fancy title or having people who report to you and call you boss. To me, leadership is taking on a set of responsibilities that go beyond what you are able to do yourself. Be responsible for the work of other people, even being responsible for another person’s growth.”

Usually, leadership can be recognized by a professional title, maybe manager, or technical lead, but engineers have opportunities to be leaders even without them. When you step ahead and take some responsibility outside of your core responsibilities, that is showing leadership.

After being asked his point of view, Jason added to the definition: “Your leadership is independent of your technical skills”. This is encouraging for developers who don’t have the most seniority in the group. You can actually showcase leadership even without being the most technically-skilled in the room.

 

What does a leader look like?

Rather than having a strict list of dos and don’ts, leadership comes in different shapes. What a leader looks like is more inherent to your organization than to a checklist, and even that is capable of changing depending on the situation. Still, there’s one thing that will help you identify your leadership or leaders within your team. A leader has a following.

You might have seen Derek Sivers’ (Founder and former president of CD Baby) Ted Talk about “How to start a movement”.If you haven’t seen it, I encourage you to do it, it is one of my personal favorites.

https://www.youtube.com/watch?v=V74AxCqOTvg

In his short and hilarious talk, he describes how a leader is made by the people who follow her/him and the capacity to embrace followers.

Now, I don’t want to get in the uncle Ben’s cliche of “With great power comes great responsibility” but having a position of leadership does come with a number of responsibilities. Steve described it as “It’s like piloting an oil tanker so if you are the pilot and you realize you are going in the wrong direction, you need to figure out where you are right now, and what speed are you going, and how fast you can turn the whole ship and you start going in the right direction. You have to make those changes in the right way. When leading people, you need to have a vision of where to go to figure out the strategy to get there, leading your people towards that.”

 

Leadership can be showcased thru these three sets of skills:

• Judgment – To be able to recognize something (intuition).
• Action – How to act to influence others.
• Communication – Verbally and written (working and communicating to the clients).

 

Born a leader and trained leader

It’s common to find these people in our lives. In school, there’s the person who runs for class president.. In your first job, you encountered the peer that volunteers for difficult tasks. Now you might find the engineer who is always willing to help people with their challenges.

These people are known as “natural leaders”. Due to personality traits, they radiate leadership wherever they go. It is just a natural reaction to situations. If you are not a natural leader, don’t worry, there’s still a second group you can fit into. Trained leader.

A trained leader might not have the same social skills as a natural leader, but that doesn’t mean she/he can’t learn how to deal with a situation with an equally successful approach.

Eric talks about leadership as “Anything that isn’t taking a requirement and turning it into code. That’s potential leadership.” This should be encouraging to all those who are not natural leaders or don’t see themselves as leaders. When you do something like saying “this requirement is wrong”, that’s an act of leadership.

Both natural leaders and trained leaders can expand their abilities through experience and mentorship. If you are a leader or are aspiring to be one, look for your company’s training programs. You can practice and improve your skills through a guided process. Also, find a mentor. Part of the job of your current leaders is to help you grow, so use that and ask them or a leader you know to mentor you during your learning process.

 

(1) https://www.merriam-webster.com/dictionary/lead

0 2 Continue Reading →

Is your organizational culture hurting your recruitment efforts?

“Why has it become so difficult to hire people in startups? Do you think you could send us more options? When would I have the first list?”

As a Technical Recruitment Leader, these are just some of the questions that I hear practically every day,  throughout the years of experience in several companies (Enterprise, Mid Sized Companies, and Startups).

I have realized that one of the most relevant factors, when it comes to attracting talent, is the organizational culture of the company. This, in turn, is part of its “Employer Brand.” Let’s accept it, saying, “I’ll talk to you about X or Y transnational company (that everyone knows about)” is not the same as saying, “I’ll talk to you about Startup Name.”

 

Organizational culture and employer branding

 

Why does organizational culture influence the employer’s brand? And how does the culture of organizations affect attracting talent?

Let’s start by defining the concept. Schein (1985) states: “Organizational culture is the way in which the company has learned to manage its environment, a complex mixture of assumptions, behaviors, stories, myths, metaphors and other ideas that define what it means to work in an organization.”

While Stephen Robbins (2014) tells us: “Organizational culture is a system of meanings shared by members, which distinguishes an organization from others.”

I would like to point out a couple of important points from the previous 2 assertions:

1) In the first paragraph, Schein tells us about how the company has learned to manage its environment. That is, how it has responded to the pressure and challenges of its environment.

Remember that a company should be treated as a person: it is a living entity that is constantly changing. It has its own character, its own form or methodology to solve problems. Also, its members “share” behaviors, assumptions, ideas, etc., that, in general, affect the way the organization works.

2) Robbins tells us about “shared meanings”, that is, beliefs, values, visions, behaviors, etc, which the majority of those who make up this group agree to follow and/or allow all of these “shared elements” to create an environment that in turn is part of the culture that is lived within the company.

 

Making your company stand from others

Organizational culture is intrinsically linked to the brand of the company since it is the way in which both the members of the company and the external environment perceive it. The challenge here is to maintain congruence between the external image (Brand) and its internal image (Organizational Culture). This drives the importance of working together with the talent acquisition department, which is the first point of contact with the candidates, so to speak: “the face of the company in the labor market.”

But how are we, as a company, different from others? This, I personally consider, is one of the most important points to be able to go out to the market looking for talent and attract it successfully.

The new generation of workers doesn’t demand only a good benefits package and flexible schedules with free coffee and snacks. In the IT industry where software developers, QAs, and support engineers have an “N” amount of options of employers, they seek, in addition to the aforementioned, to belong to a group of people who form a true work team. Where together they do something significant that generates real value to their environment, and if possible, something that allows them to leave a legacy.

Maybe it’s time to start asking yourself:

  • Can your employees explain where your company comes from? What does it do? Where it’s going?
  • Does your team have the clarity on what’s expected from them?
  • Do they know what makes your company different from others?
  • Have you identified why employees prefer to work at your company?

 

I invite you to answer these questions in your organization as a good start, and we will make sure that, in fact, ALL the members of our company understand and share these concepts in their daily lives. Believe me, and I say this from experience, having clarity on what distinguishes us, and why we are here, makes talent acquisition work a stimulating activity, where it contributes not only to “offering work”, but also being the major factor, or the vehicle to generate a true impact. And thus change life in a positive way for so many professionals who seek to work for companies where they can develop their skills, share their knowledge, and contribute to making this a better country.


For you, dear reader, how has the organizational culture of your company influenced your employer brand?

0 0 Continue Reading →

How to conquer legacy code and not die trying

As a software engineer, I know how frustrating it can be to work with legacy code, especially when your client has no idea of the level of technical debt you are inheriting, and wants you to deliver bug fixes and new features as soon as possible. If you’re as passionate about software development as I am, you’re supposed to enjoy it, not hate it. That’s why I’m writing this blog post: To share my experience and a key piece of advice about how to deal with it.

The most common issues of working with legacy code are:

  • Having no tests at all, or no useful tests.
  • Outdated dependencies.
  • Poor software architecture.
  • Technical debt.
  • Lack of documentation.

Here are some recommendations about how to deal with it and not to die in the attempt.

Risk Assessment

After performing this assessment, you’ll be aware of all the risks you’re taking (or inheriting). In the end, you’ll have to decide how comfortable you are with the given risks. Therefore it’s super important to know the current state of the project and to be aware of what to expect when it’s time to get your hands on the code.

The goal of this assessment is to learn as much as possible of the current codebase. My recommendation is to focus on the following:

  • Documentation: Unfortunately, most of the time the only documentation that you might find in an existing project is the README file, and even worse, this file is usually not up to date. Look for architecture diagrams, wikis, or any other documentation that can help you to understand the codebase at a glance.
  • Test coverage: Speaking of documentation, tests are considered the best code documentation. You should check for the current test coverage, but more importantly, check the quality of the tests. Sometimes tests check against specific text instead of testing the business logic that drives that text to be displayed. If there are good quality tests, you should be able to have a better sense of the business logic, and moreover, the current architecture.
  • Dependencies: Having a ton of dependencies is not a good sign. I always try to avoid adding a new dependency unless it’s strictly necessary, or the benefits of said dependency exceed the cost of making it happen. Check how outdated dependencies are and how difficult it would be to do upgrades. Pay extra attention when it comes to deprecated versions and you need to do major upgrades.
  • Deployment process: A new feature, bug fix, or improvement is not considered done until it reaches the production environment. You need to understand what the deployment process is since you have to take this into account while giving estimations.
  • Backlog: After getting a little bit familiar with the codebase, you need to know what’s about to come. You might be asked to add a particular feature that might not be that easy to add given the current architecture or the version of the dependencies implemented. The value of knowing the backlog beforehand is to raise any warning flags in the early stages so that you can plan.After going through each of the above points, you should be able to communicate any risks to your client. Set clear expectations and decide whether to move forward or not based on your discoveries.

Buy insurance

If the test coverage isn’t the best, you should ask to work on adding tests before adding new features. You need to be confident enough that you’re not adding new bugs while changing the codebase, and the only way to be sure is to have a proper test suite. Good test coverage is your insurance as a developer.

Refactor on the go

I know that you might be tempted to do a major refactor as soon as you start touching the codebase; however, based on my experience, that is not always the best option. A big refactor can take forever; it’s like a chain reaction. You start with a few files or lines of code, which then scales so quickly that you’re suddenly in a situation where you’ve already refactored hundreds of files with no end in sight.

A better option is to do small refactors on the go. Refactor the code you’re touching based on the features you’re working on.

The approach that I like to follow in this case is one of the SOLID principles, Open-Closed principle, which suggests that a class should be open for extension and closed for modifications. If you can’t extend an existing class or file, then create a new one following this principle, and use it only when it’s required. Avoid changing existing implementations since it can scale quickly, and you might get lost in the refactoring instead of focusing on delivering the feature.

Conclusion

Dealing with legacy code shouldn’t be that painful. It depends on your approach to working with it.

Here are the things that you should do before starting the feature development:

  • Read the existing codebase.
  • Analyze the current backlog.
  • Add tests until the point you feel confident enough.
  • Set clear expectations to your client.


Once you’ve already started the development process, these are the things you should bear in mind:

  • Avoid major refactors; instead, do refactor on the go.
  • Add tests to any single feature or bug-fix you work on.

Let me know your thoughts in the comments section. If you have any other suggestions about how to deal with legacy code, feel free to share it with us.

 

0 5 Continue Reading →

Why “Geek Out” is a key part of the TangoSource company culture

“Geek out” might seem like a strange and vague company value, so why write an entire blog post about that value alone? I recently met with a consultant who came down to our main development office in Colima a few months ago, and we were discussing her experience with us.  By comparison to different service firms in Mexico, some who have their employees drink the Kool-Aid, she felt that a key advantage for us is one particular cultural element: Geek Out.

When I wrote our company culture document a few years ago, I put a lot of myself into it, based on my reality at the time and my aspirations for what a nearshore product development shop could be. After mulling it over for a few days, I had my list, and I realized it didn’t paint the complete picture of who we are and how we work.  I added Geek Out as the last value on the list (at the time) after thinking about how much our team likes gaming, how we’ve all got different personal interests, and how we support each other’s personal expression.

 

 

Geeking out means to celebrate all of our respective individuality. In my experience, gaming helps people learn how to communicate and strategize flexibly and effectively. As you learn the rules of new games, you have to adapt. Each game has a variety of hard and soft skills, and tabletop games require that you play both the rules, and the other players. The same is true for music, dance, cooking, sports, and pretty much anything that people are passionate about.

Product and software development could be considered one of the most challenging and rewarding games in the world.  It takes years to develop the hard skills which can be more easily observed: Is your code clear, maintainable, scalable, precise, and well architected? It also takes a lot of soft skills to be more than just an efficient code monkey: empathy, proactive communication, knowing what’s going on in tech, and personal ownership of the product and customer success. To be a high-level product person means putting your entire self and experiences into your work.

So if you work with us, or want to, please understand the intent of Geek Out. The best people bring their all into what they do. Rather than stifle individuality, I feel we should help it grow and mature, for all of us to enjoy and learn from.

 

0 9 Continue Reading →

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 6 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 3 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 →