Austin Software Blog

Stay up to date on Austin Software and read articles written by our very own developers

Developer Dilema: No Time to Read the Docs

I’m actually impressed you have time to read this :)

Have you ever been on a project that required you to use new technology but you didn’t feel like you had time to read documentation?

You’re not alone. To address this problem, there’s a shift in the US to focus on products and teams and move away from transactional project based work. Product teams are long standing groups of people with different skills, collaborating to evolve a solution to a market problem. Now that we know that distributed and remote teams work well, US companies are focusing on building nearshore teams, rather than outsource projects.

To illustrate why building product teams in LATAM is a growing trend for US companies interested in nearshoring, we asked a focus group of 11 developers, from Uruguay and Colombia, about their experiences working in the Software Factory model. A significant portion of the group described that, when working on a per project model, they didn’t have enough time to do things like: read documentation, plan work, or provide good estimates. 

Check out the focus group results below to discover the future of work in LATAM and learn how Austin Software helps US companies expand their product teams in LATAM.

The Focus Group

We asked our focus group about their years of experience.


The developers range from 4 to 10 years of experience. Most developers had 4 years of experience working on an hourly or per project basis. 

Focus Group Questions

We asked developers how they felt about using project time for learning and preparation. Specifically, we asked them about reading documentation and time to plan.

When working hourly or project, I feel like I have enough time to read the documentation for my tools.
Forms response chart. Question title: When working hourly or per-project, I feel like I have enough time to read the documentation for my tools.. Number of responses: 11 responses.

Only 45.5%, less than half, of developers felt that they had enough time to read tool documentation when working hourly or per project, while 45.5% did not feel they had enough time. One developer reported that they didn’t feel the pressure personally. Clients can’t have quality software delivery if only half of their developers read documentation! This is why quality products depend on long term teams and not project teams.

When we interviewed the developers about these results, one developer gave us a quote that really captures the work quality:

“When I worked at a Software Factory that charged hourly, I actually never read the documentation, lots of Stack Overflow and copy / paste. In fact, the first time I read the docs was when I joined Austin Software!”


Forms response chart. Question title: When working hourly or per-project, I feel like I have enough time to plan my work.. Number of responses: 11 responses.

Only 45.5% of developers felt like they had the time to plan their work, while 45.5% didn’t feel they had enough time to plan. A common issue developers encounter is a sales bias during project estimation -- bidding on a project, after all, is a sales process. This often leads to stressful deadlines and poor customer satisfaction, and here it shows, given that almost half of developers don’t feel comfortable with the level of project planning.

When we interviewed the developers, one quote stood out:

“It’s hard to have any real influence over the client to make improvements because they see us as contractors. The relationship is transactional, and it’s very frustrating because I love technology.”


Austin Software helps US engineering departments expand in LATAM. That’s a big difference compared to a software factory. Our conversations with new customers don't focus on billable hours or project deadlines, instead they focus on whether the customer’s engineering department has career paths, salary reviews, bonuses, and product planning. And if the customer needs project estimates, we send them somewhere else. :)

Forms response chart. Question title: Do you prefer to work with clients on a per project basis?. Number of responses: 11 responses.


There’s a clear preference for working on a product team rather than working on a per project basis. What’s ironic is that the best product companies in the US also feel the same way, and the trend is growing! Both developers and the best engineering teams in the world are tired of the traditional project model. This is exactly the problem Austin Software solves; expand the best US product teams in LATAM, so our LATAM teammates don’t have to move to the US to work with the best Silicon Valley teams.

How Austin Software Solves These Problems and The Future of Work

We’ve noticed that the best Silicon Valley companies that want to work with LATAM developers increasingly ask us:

  • I’m sure your project managers are amazing, but can I use my managers?
  • Can I talk directly with the developers on my team? Can they be part of my standups?
  • Can my developers change their LinkedIn profile to my company?


What people are really asking is: Can the developers be my product team?

We love these questions because at Austin Software we build teams, not bill hours. In fact, we turn away companies that want to work on a per project or hourly basis. Austin Software helps companies expand their engineering departments in LATAM, so that LATAM developers can be core members of US product teams.

High functioning product teams learn together, plan together and evolve solutions over the long term. This kind of solution exploration is hard to achieve with the outdated Software Factory model. If you’d like to sign up to learn more about how the best product companies in the US are expanding into LATAM please sign up for updates below.





Thank you! Your submission has been received!

Categories

Oops! Something went wrong while submitting the form.

Subscribe to See What Positions Become Available Near You

Be the first to know.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.