Outsourcing best practices: 6 tips for coordinating internal and external development

Partnering with a dedicated team provided by an outsourcing software company can be just as challenging as rewarding.

Internal and external development teams that work on different areas of the same project need to follow a similar pace. Excellent coordination of the internal development team and the partner team can bring out the best both of these teams have to offer.

At Sunscrapers, we often collaborate with the internal development teams of our partners as part of outsourcing projects. Over the years, we have built up a set of best practices that allow us to navigate these relationships smoothly and deliver amazing work.

Here are 7 things we’ve learned about coordinating internal and external development teams that are essential if you're planning to outsource a part of your IT project.

1. Pick the right project management tool

The most significant challenge in coordinating internal and external teams lies in communication. Managers should put some thought into that subject and educate their teams about when to communicate, how to communicate, and what tools to use. Naturally, culture is a significant determinant of how you organize the communication habits in your teams.

To avoid email clutter, implement the right project management software. That way, you will develop a centralized system where all the comments, questions, and suggestions are stored where they belong. Sounds better than filling up inboxes and creating multiple strands where details get lost easily, right?

Sharing a place where work is organized and managed, both teams will enjoy the benefits of greater transparency and won't have to update one another manually about the work being completed in each.

2. Meet regularly

If you're planning a development collaboration between an internal IT team and a software provider, holding regular meetings is essential. By doing that, you'll ensure that everyone advances at a similar speed and all functionalities are integrated smoothly.

It's good to have a weekly meeting of internal and external development teams during which you identify goals, check who will be working on them, and define when they must be completed.

Teams can also use these meetings to share status updates and information about ongoing risks. During your cross-functional development meetings, you need to ask both teams whether they're on track, experiencing any blockers, or have any questions.

3. Avoid re-work

Another challenge in setting up an efficient communication routine for your teams is avoiding rework by one of these teams. That may happens when, for example, two teams fix the same bug.

By equipping your development teams with a space where members can check what each person is working on you'll avoid duplication of effort.

Granting everyone accesses to code developed by both teams is a smart move as well. That way, you'll make it easier for team members to reuse code the other team is developing.

4. Plan code reviews across teams

Schedule weekly catch-up meetings where teams share their work and tell you what they're up to. But also organize regular code reviews where teams can have a detailed look at what each of them is writing. Establish close communication between team leaders in that matter as well. 

For example:

If you know that the team from your software partner will be adding a component you can use soon, it's better to wait for a little and take advantage of it when it's ready instead of implementing it on your own.

5. Find the balance between control and flexibility

When outsourcing software development, it might be tempting to either hover over the team too much or ignore it completely, trusting that it's best left on its own.

To stay productive, you need to strike a balance between these two approaches and make the collaboration between your internal and external teams work smoothly.

For instance, establish specific checkpoints and stick to them – but allow for some flexibility. Whenever a task doesn't meet your schedule, find out why that happened and move on.

Trust the external team, but show that their work is critical to the overall progress of the project and needs to meet particular requirements you agreed upon.

6. Avoid micromanaging the external team

Project managers often find it hard to let go of their responsibilities, especially if they're developers themselves. Instead of focusing on project goals and communicating problems, they concentrate on finding solutions for these problems and offer implementation details so that developers can simply do what they're told.

That practice is particularly dangerous when you're managing remote employees. By doing that, managers will be losing too much time on tasks for which they hired the remote team.

Moreover, the external developers might feel undervalued and unmotivated because they get robbed of the chance to be innovative or creative.

Problem-solving is what developers do for life, so taking that element out of the equation and turning the external team into a group of automatons is a serious mistake that might cost you a lot.

7. Identify responsibilities and make them crystal clear

You need to define responsibilities as you set the expectations for the project. It’s a good idea to inform the team about deadlines and other requirements at the very beginning of cooperation.

Will the entire project management stay on your side or will you need the support of an external project manager who supervise the work of the external development team? You need to ask yourself this question early on in the process to avoid any misunderstanding and ensure your project proceeds smoothly.

Key takeaway

Just like everything else in life, coordinating internal and external teams is about finding the right balance. You don't want to fall into the trap of micromanaging your teams, but you also don't want to leave the external team to its own devices.

Excellent coordination of these teams will render your development process far more efficient because they will be able to take advantage of each other's work, skills, and expertise. They will complement each other where it matters most.

If you're looking for a team of tech experts, get in touch with us.

Our software development teams have the experience and know-how to make outsourcing collaborations successful.

How to choose the right custom software development company

Companies can't survive on the market without quality software.

The right software can make or break a business. It helps to boost employee productivity, creates amazing experiences for customers and streamlines company operations.

“Every business is a software business,” said Watts S. Humphrey. He said that a long time ago, but he couldn't be closer to the truth.

So what can companies do when they need software? Out-of-the-box solutions are usually the first step. But most of time, they’re not enough to adequately support all the processes at an organization.

That's where a custom software development company comes in.

In this article, I'm going to talk about the critical benefits of custom software development and some key things leaders should consider when hiring a custom software development company.

Ready? Let's dive in.

Why custom software development?

Custom-made software is always perfectly adapted to match the demands of a company. Packaged software, on the other hand, offers the same, more or less customizable features to everyone who buys it.  

That’s why off-the-shelf software often falls short when it comes to meeting diverse organizational processes, requirements, and goals.

Here are some key benefits companies get when they invest in custom software solutions:

• Optimal integration – growing organizations usually end up working with multiple tools. That makes licensing more difficult and keeps vital data siloed. Developing custom-made software allows integrating various processes into a single place and consolidating all the relevant data for valuable insights.
• Full personalization – One-size-fits-all software doesn't exist. Have you ever seen two companies that have identical processes, teams, and tools? That's right, you probably haven’t. Custom software fits seamless into an organization and meets all the needs of its workforce.
• Scalability – off-the-shelf software might work for you today, but what about tomorrow? As your company grows, its core processes will change. By sticking to packaged software, you risk ending up with tools that keep you from scaling your business. A custom software solution will support the growth of your business and continued maintenance services ensure that it scales effectively. 
• Excellent ROI – sure, developing custom software might be costly, but it's worth it in the long run. You won't have to spend time and money on changing and expanding a packaged solution to accommodate your changing needs. Also, off-the-shelf software may include extra costs like licenses.
• Maintenance and support – the critical benefit of custom software is that you get more than development. The team responsible for building your solution will also provide support and help you maintain it. Reliable technical support offers great value to businesses that want to thrive.

Now that you know why investing in custom software is a smart move let's have a look at the essentials of hiring a software development company.

Here are 6 things you need to review when choosing a custom software development company.

1. Define your objectives, resources, and timeframe

Before launching your search for the best software development team out there, define the business objectives your solution will support. What kind of problems would you like to solve? Which business goals should the solution help you achieve?

Make a list of a few key goals for your software and explain how your solution will tackle each of them. Develop a realistic timeframe for your project and think about the resources you'll be allocating in it. Approaching a software development company with that info will make everyone's life easier.

2. Start by getting referrals

You surely know people who have collaborated with software development companies. Start by reaching out to them and ask for referrals. That helps to fast-track the process of selecting potential development teams, but also allows gathering honest feedback about their work.

3. Take a look at the company portfolio

That section of a company website offers a lot of valuable information. By reviewing the company portfolio, you'll understand what type of applications the team has worked on. That will help you check whether the company has the expertise and know-how to develop the solution you need.

Companies that have little experience in creating custom software may not be familiar with challenges that surface during the software development lifecycle and the specificity of building custom software for businesses like yours.

Expert tip: Focus on the size of the projects delivered by the team. Most custom software development companies specialize in particular project scopes. For example, they take on multi-year projects or build business intelligence solutions for specific, regulated sectors like finance.

4. Check out the company's technology stack

It doesn't matter whether you're reviewing a young development team or seasoned software company with many years of experience. You need a partner who follows the tech industry closely and invests in the latest tools and technologies.

A company like that is open to adopting cutting-edge development processes, learning new skills and technologies as they emerge, and taking advantage of battle-tested approaches such as agile or scrum. Technologies change faster than ever before, so the development team should future-proof the automation of delivery processes by using different continuous integration tools.

Learn more: 4 things that separate great developers from average ones

Team up with a forward-looking and constantly learning tech team that has an excellent track record of delivered solutions and proven expertise to build software you need.

Take a close look at the company portfolio and ask yourself these questions:

• Do you spot innovative technologies?
• Are the applications well-designed and offer excellent user experience?
• Does the company share its approach or process for developing software for particular target groups?
• Did they build software for companies that are in any way similar to yours?
• Do they provide continued support and maintenance?

Expert tip: It's better to hire a team that specializes in a particular technology than one that offers a broad range of services that happen to include the tech stack you need. For example, if you're looking to build your solution with Python, choose a company that focuses on it (like Sunscrapers!) instead of a large organization that has used Python in a relatively small fraction of its projects.

5. Consider the geographical location

When outsourcing software development, you might be tempted to hire a team on the other side of the planet just because it offers cheap services. But when it comes to building software, cheap is always risky. And that's just one potential problem that surfaces when you team up with a company located in a remote country that has an entirely different culture, customs, and language.

Here are a few things you need to remember when teaming up with a software team in another location.

Communication

Successful collaboration requires communication. And that can't happen if the company you're teaming up doesn't speak your language fluently. Software development is a complex process and communication troubles will make it hard at every step of the way, from defining requirements to giving feedback. Pick a company that has previously collaborated with companies from your region and speaking your language. That way language will never become a barrier.

Learn more: Your recipe for successful remote team cooperation

Culture

There's a reason why Eastern Europe has become such a popular outsourcing destination. It offers top programming skills and expertise, but also a professional culture that is similar to the Western one.

Partner with a development team that shares some elements of your culture and knows how to collaborate with companies from your location. For example, here's our recipe for success built on our collaborations with companies from New York City.

Learn more: How company culture impacts outsourcing partnerships – and what you can do about it

6. What happens after development

When talking to potential technology partners, don’t focus only on custom software development services. Ask about after-development support services as well. They should be willing to commit to providing you with services such as configuration, orientation, customization, as well as maintenance and backup services.  

When it comes to custom software, you're the one paying for it and should become its owner. Make sure to clarify that point. Your contract should include an ownership clause that complies with the laws of the governing state.

Building custom software is always a good idea

If you want your business to succeed, you need to equip your teams with optimal tools. And only custom-made solutions can offer 100% coverage of your needs, taking into account that these requirements will change over time as your business grows.

If you have any questions about developing custom software solutions, reach out to our team at hello@sunscrapers.com. They'll help you take your first steps towards developing a solution that empowers your business.

Building tech products without technical competences

I’ve worked as a Manager in both software development companies and product development teams. I know what kind of problems non-technical founders face. While working at software development companies as a project manager, I’ve been helping them throughout the entire product lifecycle. I worked with founders with no technical knowledge, technical pros without any soft skills, and geniuses who had incredible technical and business skills. In short, I’ve seen it all. And I’ve learned this: Technical knowledge isn’t a must-have for building amazing technical products. But that’s not an excuse to ignore the technical side of the project altogether.

 

Founders without technical skills often make these mistakes

In my experience, non-tech founders sometimes:

1. Believe that their vision is enough to support the project and don’t take extra care in finding matching technical expertise, instead of relying on randomly-chosen software development companies or freelance developers.
2. Are so intimidated by the technical side of their project that they either never realize their idea or lose their independence to technical partners.

As you can see, in both cases founders fail to embrace the technical side of their projects. They miss out on the incredible opportunities bridging technical and business worlds offers. Here’s my solution.  

Let’s start with founders

Who is a non-technical founder?

• Business driver
• Responsible for driving sales/driving growth
• Has a clear vision, feels the mission, and focuses on solving real-life problems
• Makes business decisions

What kind of knowledge does he or she need to realize their project?

• Business knowledge - sales, marketing, communication, ability to reach target audiences and analyze their needs.
• Domain knowledge - knowledge of the market and its problems.
• Knowledge about how to pitch investors or how to fund a business - understanding different kinds of sources of capital and alternatives available on the market.
• Knowledge about how to verify a business idea - prototyping, lean startup methodology, different business models, MVP development.
• Plus: Key personality traits: determination, goal-orientation, hard-working, belief in their vision.

That knowledge is enough to build a great tech product. But successful founders are the ones who fully embrace the technical side of their project and take responsibility for it.  

Embracing the tech side

If you’re a non-tech founder who wants to build a tech product, there are a few ways to get your project on the right track:

• Find a CTO
• Hire a freelance developer and monitor their work
• Find a tech partner (a software development company or digital product consultancy)

 

Find a CTO

This methods has its advantages and drawbacks. Here are some of them to help you decide whether this is the right course of action.

• You get technical expertise on board
• In-house quality assurance
• Finding a CTO who has the right skills and is a perfect project fit is very difficult. You’re looking for someone with interdisciplinary, full-stack competences such as backend and frontend development, development team management, low-level problem-solving, high-level analysis of product architecture and technology choice.
• Hiring a CTO is expensive (high salary/shares)
• It’s not easy to find the right combination of technical and business skills.
• A CTO is a short-term solution because as your product grows, it will require a lot of coding and you’ll need to hire someone eventually.

  Case study scenario: A young, inexperienced entrepreneur looking to reduce product development costs maximally acquires a CTO as a partner. The non-tech founder is then responsible for sales and building product awareness among target audiences. The CTO codes the first version of the product - the Minimum Viable Product (MVP). After a few months, they have a sellable product that brings value. Challenges? For starters, it’s tough to find a CTO who is skilled, trustworthy, and engaged in the project. A CTO is usually an experienced tech expert who can get an amazing job with a huge salary at any company, so their alternative cost is high. If the product isn’t bringing the expected results, a CTO may lose faith it in and become discouraged. Moreover, quick product scaling will require more people on board, so an interdisciplinary skill set is crucial to building a technical team.  

Hire a freelance developer and monitor their work

This is a popular method for taking an idea for a tech product off the ground. It has many benefits, but also some disadvantages:

• Potentially the cheapest solution for building a product.
• High flexibility - freelancers work for several clients at the same time and are willing to apply small changes to products.
• Great solution for small projects (lasting 2-4 weeks).
• Finding freelance developers is faster than hiring in-house.
• Hiring talented developers is difficult (massive competition on the market).
• You need the skills required to manage and supervise the work of the developer (for example, defining project scope, development process management, quality assurance).
• Not a good option if your project scope isn’t well-defined.
• Consider the hidden costs.

  Case study scenario: You’re so excited about your idea that all you focus on is finding someone who could bring it to life. Platforms like Upwork are helpful for finding freelancers. If you source your developer globally, you’ll find the right person easily. You may even feel that you two understand each other. You brief the developer, and he or she sets down to work. But what you get doesn’t match your expectations. That’s because it takes a lot of time and energy to define your product requirements. It’s something you’re still learning at this point. A solution to that is hiring an experienced project manager who would supervise the developer. But it’s tough to do that on a low budget.  

Find a tech partner

Finally, non-tech founders may team up with a software development company that has ample experience in building tech products. Here are the pros and cons of this option:

• Extra competences on board (UX, design, DevOps, full-stack development, project management skills, battle-tested processes, demanding recruitment, sometimes also business support such as go-to-market strategies, product strategies, product discovery, scoping sessions).
• You can create a team that matches the requirements of your project perfectly.
• Offshore options are best when it comes to cost-effectiveness.
• Development companies are used to realizing projects coming from different sectors. Working with founders, they accumulate knowledge about common mistakes in product development. But founders should also look into the specialization of development companies - for example, when looking for e-commerce companies, pick those that have an excellent track record in this area.
• It’s challenging to pick the right partner from companies that look very similar at first glance (the market motivates more and more “newbies” to join - which increases the risk of not finding the right match).
• It’s essential to carry out this process carefully and comprehensively because there are many companies of questionable quality out there. That’s why you need to be 100% sure that communication with the chosen partner and their workflow won’t cause any problems.
• You need to find a partner experienced in remote work.
• Working with a tech partner is an excellent solution up until a certain point when you scale your business and need an in-house technical advisor (that’s when you hire a CTO).

  Case study scenario: A tech partner delivers the product but also often serves as a business advisor. That doesn’t mean a well-done job on the product side guarantees its instant success. I have seen cases where founders counted on building an application and spreading the news among friends to get a snowball effect and bring in lots of new users. Unfortunately, that’s just not how the market works. It’s just way too competitive. Partnering with a tech company won’t bring you success if the product doesn’t fulfill a market gap.  

BOTH business drivers and technical rockstars build successful tech products

If you want to build a tech product, you don’t need technical skills. But you need knowledge about product development and business models such as Minimal Viable Product (MVP), Lean Startup and Agile methodology. It allows entrepreneurs to verify their ideas and business assumptions at an early stage to enable successful product development and launch. Building an MVP is the ultimate objective for all technology entrepreneurs. But they often fail to understand what an MVP is all about. It’s not only the first working version of the application, but also a simple product that provides value and fulfills a need on the market.  

Ok, so you’ve already found your product-market fit. What's next?

The Ansoff Matrix can help you. It’s a tool that facilitates strategic decision-making. If you found a product-market fit, then your market share is probably still negligible. That means the first strategy for the development of your business is to continue penetrating the market. To achieve that, increase sales volume and marketing activities. Technological expertise isn’t a bottleneck here. But you’re not alone on the market. Almost every industry suffers from hyper-competition. Copycats quickly follow newly-created niche products. That’s where these two strategies come in: market development and product development. I have often encountered cases where an application needed refactoring to scale the solution, develop the product efficiently and avoid spending long hours on patching the spaghetti code (which in this case was the result of the many pivots on the way to finding the product market fit). Regardless of the direction in which you go - having in-house technological competence will be of great value to you. Even if you start without a CTO on board and work with a freelance or technology partner, there will come a moment when business decisions will require an understanding of the product’s tech part. So get started right now.   ----- Many thanks again to Huthayfa who invited me to give this talk at the Digital Entrepreneurs UAE in Dubai on November 14 2018

What’s it like to be a Lead Developer at Sunscrapers? Interview with our CTO, Przemek Lewandowski

We're currently hiring a Lead Developer to help our project managers and development teams build amazing products. Here's a short interview with our CTO, Przemek, who talks about this exciting role in detail.

  Kamil Sabatowski, COO at Sunscrapers: When I joined Sunscrapers, it was already an established company. Could you tell me a little more about your responsibilities in the early days of the company? Przemek Lewandowski, CTO at Sunscrapers: Eight years ago, I was a CTO in a small company that back then counted only a few people and I was responsible for many different things. It's normal to wear many hats when the company is at its initial stage. Back then, I oversaw projects developed at the company, but also played a central role in our recruiting process. I'm still involved in project management and recruitment today but on entirely different terms.   Kamil: Let's start with recruitment. How did that change over time? Przemek: My job has become much more relaxed ever since we established a solid recruiting process at our HR department. Our Talent Manager Martyna, is the one responsible for non-technical issues like culture fit or communication skills. But she also asks preliminary technical questions that indicate the candidate's knowledge in a given area. That way, I know that the candidates she passes on to me have the necessary skills. That makes the next stage of the process - the technical interview and trial task - much easier. Before meeting the candidate, I check Martyna’s notes to learn more about that person. During an hour-long interview, I ask questions that cover anything from the candidate’s understanding of programming paradigms and solutions to the knowledge of abstract, high-level concepts and best practices. I then write down some notes and if I feel the candidate is a good fit for a project, I schedule a meeting with our executive team to discuss hiring that person.   Kamil: That means our prospective Lead Developer will have an easier time building a team? Przemek: That's right. Like every development company, we need talents on board, and that's why we designed our recruitment process to be as smooth and pleasant for the candidate as possible. We never ask trick questions, but create an open space for knowledge sharing and discussion. Many of our questions are challenging, but we don't expect candidates to know everything in detail. We want the interview to be a learning experience where two parties exchange knowledge and check whether they're compatible. We always ask candidates about how we did after the meeting and usually get good feedback, so I'm glad to say that it's working. The Lead Developer we’re looking to hire will face two different challenges when building teams at Sunscrapers: they will need to verify the candidate’s technical skills and mindset.   Kamil: Now that we covered recruitment, let's move on to the second area – project management. Przemek: When stepping into the role of a Lead Developer, I had a range of high-level tasks related to requirement, sales (technical analysis, consultancy services, preparation of quotes and building client relationships), and participation in projects. The latter is quite complex because a Lead Developer is responsible not only for planning the architecture and choosing tools, but also mentoring the team with the help of regular code reviews, pair programming, problem solving and direction, and providing feedback on technical solutions and decisions. Finally, the Lead Developer is also responsible for monitoring team processes and quality through code reviews, offering teams better solutions and making sure that the process follows industry standards (with automated testing, continuous integration and delivery, knowledge sharing between team members).   Kamil: And that's also what you would expect from the Lead Developer? Przemek: Exactly. We're looking for someone who would be able to step in when needed and code together with the team, on top of making critical decisions that set the project's direction. Being able to switch from a high- to a low-level view of the project is an essential skill. But our focus is mentoring. We want our Lead Developer to mentor less experienced team members, showing them opportunities for growing their skill sets in synergy with projects.   Kamil: Could you tell me a little more about collaboration with project managers? Przemek: We have project managers on board who are responsible for communicating with clients and coordinating the work of the development team. The project manager ensures that the team is working following established processes and best practices and organizes project meetings. But project managers usually don't have in-depth technical knowledge – and that's where the Lead Developer comes in. The Lead Developer shares their responsibility with project managers in some areas, but not other – that's how we avoid the risk of the Lead Developer becoming responsible of tasks that don't take advantage of their technical expertise.     Kamil: What are the primary responsibilities of Lead Developer in collaborating with project managers? Przemek: A Lead Developer advises the project manager on technical matters. A person like that needs to be able to explain complex technical concepts in a language accessible to a non-technical person. Sometimes we implement functionalities that are technically very complicated and or require solutions the project manager doesn't know and can't accurately predict how much time such a task takes. The technical complexity of tasks may affect their priority in the backlog. The Lead Developer explains these issues to the project manager using their knowledge and experience. For example, the Lead Developer can suggest to the project manager that they develop a slightly different functionality that would allow saving 80% of the time, opening a conversation with the client. The Lead Developer needs to guide the project manager through these alternative options, working together on the backlog, helping the PM in estimations, and identifying project requirements. At the same time, the Lead Developer shows the PM potential problems in the team process or missing skills, and explains the technical decisions of the team and their consequences for the project.   Kamil: Does the Lead Developer communicate with clients as well? Przemek: Sometimes the Lead Developer needs to explain complex technical issues, and the best way to do that is through direct communication with the client. That's also an opportunity to present recommendations on the basis of their experience in other projects.   Kamil: So the Lead Developer is part of the process, but not on the operational level? Przemek: We have developed and optimized our processes to offer the Lead Developer as many opportunities as possible to make the most of their skills and knowledge. That's why we left the general project organization and client communication to project managers. Naturally, the Lead Developer needs to keep a close eye on the process to make sure it follows best practices.   Kamil: Could you give an example of that? Przemek: Imagine a situation where we have a less experienced team member who uses the daily morning standup meeting to share their problem. Knowing that the daily standup is dedicated only to discussing the project's progress, the Lead Developer will have to pinpoint the moment when the discussion goes into too much detail. They will suggest sharing the status and information about problems with the entire team, but discuss these issues in detail after the standup and try to solve them together. We expect our Lead Developer to support the development process that way and strive to optimize it.   Kamil: What does a day in the life of a Lead Developer look like? Przemek: That's a great question. Experienced developers are still developers who love to code. A typical error of Lead Developers is that they fall into solving technical problems before checking whether the team has any. That's why they should start the day by making sure that the team doesn't have any technical issues – including the project manager. Next, there's the verification of what the team is up to – like checking the direction of the project or performing a code review. Sometimes the team might claim that everything is running smoothly, but when you look at the code, you instantly see that they're following an entirely different direction. The second half of the day is a perfect time for scheduling meetings, sprint reviews, retrospectives, or even meetings with candidates (but we're flexible here).   Kamil: What brings you most satisfaction when you are playing the role of a Lead Developer in our projects? Przemek: Mentoring team members is great. But what brings me the greatest satisfaction is the moment when the person I've been mentoring creates something great. That's when I see how my knowledge and experience are now part of that person, leading to their personal growth and greater autonomy. Then there are of course the milestones we pass in developing projects. Finally – and I guess that's how many developers feel – there's the feeling when we eventually see that we picked the right tools, technologies, and architectures for the project. That's not something we can predict at its beginning, and there's always some risk involved. It's great to get the final confirmation of something we believed all along.  

If you're looking for new challenges and want to work on exciting projects at a company that takes extra care in the personal development of its team members, we invite you to apply to become our Lead Developer.

4 things that separate great developers from average ones

The web is full of tips and tricks for becoming a rockstar developer. Top IT managers, agile evangelists, and prominent community members are all busy painting the picture of an ideal software developer capable of generating amazing results. In reality, the line between an average developer and a great one is very thin. Consider this: The profusion of learning aides like online courses or development schools, as well as enthusiastic knowledge-sharing practices of the developer community has lowered the entry barrier to the profession. An increasing number of young, inexperienced people are part of the IT industry today. But technical expertise isn't enough to take a developer from average to great. Here are 4 serious mistakes made by inexperienced developers that inhibit their growth and prevent them from entering the path toward greatness. These errors are so obvious that it's often hard to identify them as such – even by well-coordinated and experienced teams.

4. Always choosing custom over ready-made solutions

When we face a sizeable creative task, we're often tempted to build a specific functionality from scratch. That's what brings us the most satisfaction. However, before jumping on the custom-solution bandwagon, it's worth to take a moment and reflect whether we really need it. Technological solutions function in the business context. Is it really a good idea to spend money on building a custom functionality that doesn't bring users value? Don't forget about the future costs that come with maintaining that custom functionality. On the other hand, you've got open-source solutions that are available free of charge and maintained by communities of passionate developers. If you want to provide users with a specific functionality, consider your current budget and future plans for your product development before going for a custom solution.

3. Forcing new technologies at all cost

Technology trends come and go – so quickly that most of us find it increasingly difficult to keep up with the many different directions the industry takes today. Everyone is asking themselves questions like: Should I choose a native language such as Java, Swift, or maybe React Native for my next mobile project? Or rather go for the Progressive Web App instead? Following new trends is easy because everyone else seems to be doing it. So how can we judge which trends are short-lived and which ones stand a chance to disrupt our industry? Even experienced developers are tempted to ride the wave of recent trends. What they often do is quickly mastering such technologies and then trying to implement them in the first commercial project they get their hands on. When expanding the technological stack of a project, they're surely led by good intentions – they want to make sure that the product develops according to new industry standards. Naturally, developers who actively follow the sector developments and gain new skills are among the smartest of the bunch. But when they fail to take into account the long-term consequences of their technology choice for the team or its direct business value, implementing new technologies at all cost can become problematic. Sometimes developers suggest a hot technology just because they want to learn it and seek an opportunity for doing so. Sticking to personal goals instead of the company's business objectives in technology choice puts the project in danger. Team knowledge of new technologies (or lack thereof) acts as a buffer here because it reminds everyone that forcing new solutions can be extremely costly – especially if the developer initiating its implementation leaves the project later on. Trending technologies don't become widespread instantly, and the low market penetration of a specific technology makes it difficult, slow, and expensive to attract experts in the field. Not to mention that new technologies often don’t get the chance to pass through extensive market testing and might be buggy. This is another threat to the project that results directly from the developer's failure to take into account the potential negative consequences of forcing innovative solutions at all cost.

2. Estimating undefined tasks

Some developers forget that every defined task derives from an undefined task. That's especially true at the early stage of the project. There's nothing wrong with asking for additional information, details, extra attachments, accepted wireframes, or final designs. The problem arises when the task isn't well defined and developers have doubts or fail to consider potential scenarios – and yet they try to estimate the labor intensity of such a task. The larger the problem is, the more important the estimations for the project are. Asking questions should be the norm, but for some reason it’s still very often not. Information is essential for analyzing the scope of the task before attempting to estimate its workload. Short research is a must at this point – for example, reading the product documentation or outlining key technical steps that must be performed to complete the task as expected are very helpful. Developers who aren't afraid to ask questions boost their chances of delivering a product that matches the vision of the product owner, client, or other stakeholders.

1. Not communicating errors

I know what you’re thinking. This problem is so obvious that it almost doesn't occur anymore. Not in my experience. There are many reasons why developers hesitate to communicate errors. Daily standup meetings during which the team doesn't report any problems is a potential red flag, and experienced PMs need to increase their vigilance. Think about it this way: When a developer joins a team and instantly receives the title of a “senior developer,” that status comes with a lot of pressure, and they might find it hard to admit that something isn't going as planned or is taking longer than estimated. It might come as a surprise, but there's a lot of creative work involved in a developer's daily job – and not all solutions are immediately obvious. That's why a developer's experience is measured in how they approach tasks or use tools to search for solutions, and not whether they can answer all the questions. And let's not forget that speaking about problems is still perceived negatively and puts the person talking about project issues in a bad light. That's why it's essential that we build teams immersed in a culture of openness, where everyone can share their problems, mistakes, and hardships. Only teams with a strong culture will achieve synergy, boost knowledge exchange, and foster honest communication about problems. All that facilitates product management too and is particularly important for product owners, project managers, and other stakeholders (such as executives, investors, clients).

So what does it take for a developer to become more than average?

In my experience, there are 3 factors that put developers on the path to greatness:

• • Company culture – a culture that promotes honesty in communication and professional growth helps developers learn more about their area of expertise and become better at their jobs.

• • Good work habits – good habits help developers work more effectively. Instead of spending hours writing code mindlessly, developers who know how to manage their time find space for higher-level problem-solving tasks and education. Moreover, knowledge of good practices helps to avoid making mistakes that create technical debt (which will take up the time of other team members in the future).
  • Passion and commitment – developers who love what they do are fully involved in creating the best solutions. They think holistically about the entire application architecture, not just the single functionality to which they were assigned. And they always go the extra mile.

As you can see, all it takes is paying attention to communication practices, team culture, and work habits to eliminate some of the most serious problems that inhibit developers from growing and thriving. At Sunscrapers, we have developed a project-oriented culture that promotes knowledge-sharing, transparency and orientation toward tangible business goals. What else do you think separates great developers from average ones? Share your thoughts in comments!

Product development explained: Why your product requires different models of support in each lifecycle stage

  Let's make one thing clear: your product will require different kinds of support throughout its lifecycle. There's no denying that every product development process looks somewhat different, but you can be sure that it always follows the same lifecycle. A typical lifecycle can be divided into three major phases: idea conception, production, launch & growth. Each stage sets different challengers to founders and production teams responsible for bringing the product to life. Here's everything you need to know about each of these stages to fully support them and build a fantastic product.  

Idea conception

[bctt tweet="“Plan carefully, then execute rapidly” - William G. Bowen, President of The Andrew W. Mellon Foundation"] Careful planning is essential to successful project execution. When planning your product, you need to consider its entire context. And that means that you should be thinking about how you will approach software development, but also develop your business model. That includes considerations about your Unique Selling Proposition (USP), monetization scheme, critical processes, and partners – as per the Business Model Canvas. You also need to prepare a viable go-to-market strategy where you define the scope of your Minimum Viable Product (MVP), but also how you would like to test your app, gather customer insights, and grow traffic. How to get all that done?

• Do your homework and research everything from the market to customer profiles;
• Host workshops, brainstorming sessions, Q&A sessions;
• Rely on the experience of people who know how to set up efficient plans (business strategists, system architects, senior designers, and founding partners;
• If you're starting from scratch, team up with a product design company that offers business strategy skills, not a software provider who will only code according to your specification. If you resort to the latter, you risk developing a product that doesn't match any market needs, even if it's well-built;
• That's why it's a good idea to hire a team that complements your skills and provides you with a 360 expertise.

 

Production

Once your product idea is developed, you can proceed to hire a team for product design and development. At Sunscrapers, we follow the agile methodology and break down the entire scope of the work into epics and user stories. That way, we can estimate the workload in advance and set the right priorities right from the start.

At that point, you also need to choose the scope of your MVP and decide which features are necessary for the MVP to provide value to the first users of your product.

When you're sure what kind of an MVP you want to build, we create the best team for the project and proceed with design and development. Working in iterations, we build on the MVP to arrive at your product vision. Note that this phase requires some flexibility. We like to involve various competencies when needed ranging from UI design, web or mobile development, and testing capabilities. Bringing in all these different skills is critical for developing a product that matches your design. We also align the process to reflect business or stakeholder requirements – the speed of delivery vs. scope vs. product quality vs. cost.  

Launch and growth

That's where the fun part starts. The requirements for this stage in product development lifecycle are entirely different than during the previous phases. Unfortunately, it's easy for things to fall apart here because many dev shops aren't prepared to handle that stage and fail to educate clients.

So what exactly changes here? You basically open your product to the public.

Expect to receive feature requests not only from internal stakeholders but users. It may become more challenging to manage the backlog and set your priorities as you become afraid of losing the early adopters due to problems like poor UX or support. Your platform is live now, so it needs constant monitoring. Emergencies like server outages require full responsiveness. You might uncover bugs or scenarios that may require your immediate attention. Don't panic: That's completely normal to any software development project. Remember that each platform you choose (web, iOS, Android) will require support from a different specialist and all of them will need to provide that support on a continuous basis, not ad hoc like in previous stages in your product lifecycle. As the project's founder, you're taking care of production, but also about promotion, analytics, fundraising, and million other tasks. How to deal with all that and survive?

• • Remember always to set aside a budget for maintenance and developing new features after the launch.
  • Consider hiring a dedicated team if you can't guarantee responsiveness and day-to-day availability.
  • A dedicated team can devote a part of their time to maintenance and the other part of developing new features.
  • Consider working with SLAs. They might come in handy at this point, but don't forget that they are usually the domain of large enterprises and their goal is to maintain a product, not scale it. SLAs aren't the best option for startups or innovative environments.

 

Key takeaway

One of the most common mistakes I see founders commit over and over again is this: they focus on production too much and forget about planning and supporting the product after the launch. Likewise, many dev shops concentrate on the production phase and just don't have the skill set to help founders regarding strategy or the capacity to support scaling.  

When looking for a dev shop to create your software product, look for companies that can support you with 360 services and become a real partner during the entire journey, not just the beginning.

  Last but not least, always set aside a budget for maintenance and growth – don't forget that the production stage is only the beginning.   Have you got any questions about developing software products? Or perhaps you have some other tips up your sleeve? Leave a comment and share your experience to help the community learn more about best industry practices for developing fantastic software products.