This year I challenged myself to get out of my comfort zone and switch from the corporate software industry to work at RokkinCat, a software contracting company. After 5 years at the same job, I found that I wanted exposure to different technologies as well as new challenges so that I could continue to grow as an engineer.

Since I started working for RokkinCat, I have had to shift my perspective to be in alignment with the small business mindset to ensure that both my company and our clients are successful. Here are the top three things I have learned so far:

1. Software contracting success is closely coupled with client success.
2. Development work must align with the MVP.
3. Technical iteration is often expected.

Software Contracting Success is Closely Coupled with Client Success

This is a bit of a no-brainer from a small business perspective, but coming from an engineering background it was new to me!

RokkinCat is a small company, so each contract that we land is very valuable to us. We strive to help our clients grow their business and increase their revenue stream by growing their product offerings.

When our clients are successful, they choose to continue our working relationship which in turn makes RokkinCat successful. If the extent of the work has been completed, our clients can help connect us to other potential contracts from people within their network. With this relationship dynamic, it is in our best interest to help clients achieve their own success.

The interesting thing about customer success is that it looks different for each client. Sometimes a client needs a solid product that will scale, while other times the client has an important deadline that needs to be met to increase buy-in from investors. Each company has different needs, and we work closely with them to ensure our own success as a software contracting company.

This is a different client-to-customer relationship compared to what I have experienced in the corporate industry. If your company has a larger customer base, it is in your best interest to prioritize incoming feature requests/bug fixes based on what will provide the most value to the majority of your customers (or your largest clients). When compared to a small company, this is a much more hands-off approach to ensure all your customers reach their maximum potential.

Development Work Must Align with the MVP

The Minimum Viable Product (MVP) is a phrase in the software industry that indicates the smallest amount of work to get a bare-bones product into the hands of your customer. If you are unfamiliar with this term, please see the wonderful article that Sabrina has written about it: Someone Told Me to Build an MVP.

When identifying an MVP with a client, we take into account product requirements, technical limitations, long-term goals, and our client’s budget. The budget is the major limiting factor in many cases, so we want to ensure that we don’t spend that budget building features that are outside the scope of the MVP. Our goal is often to get our client’s product off the ground, so they can start generating revenue.

The tricky part is that it can often be exciting for clients to see progress being made towards their big-picture vision and will sometimes ask for changes that are out of scope of the MVP. As a software contractor, it is important to recognize when an request is out of scope and have a conversation with them about the importance of prioritizing features that work towards their MVP.

This is very different from working in the corporate industry as a developer because the priority of work has already been decided for you by product managers and software architects. By the time the work arrives in the hands of a developer, the company has already thoroughly reviewed the priority of the work.

Technical Iteration is Often Expected

Building the MVP is only the beginning of bringing a client’s big picture vision to life. The MVP is designed to get the product into the hands of the target customers early so our client can begin to provide value.

Once the product starts providing value back to the company, we can then spend more time expanding the scope of features, making the product more scalable, and investing more time and quality into the project.

With this mindset, we have to work hand in hand with our customers to discuss the tradeoffs of how we build the MVP. Sometimes it is more important to implement short-term solutions to ensure our client has a revenue stream rather than implement long-term solutions that will eat up the project’s budget before producing an MVP.

This is a very different mindset from working in the corporate industry where an established company already has a consistent revenue stream to fund its technical projects. They have the time and money to invest in their product upfront without having to go through as much iteration as a small business would.

Takeaways

Transitioning from corporate to software contracting has been a big shift in mindset, but it has been a rewarding experience. This year I have really learned a lot about what it takes to be a good software developer in the contracting space, and I look forward to learning more as I face new challenges and opportunities.

Check out the original post on Erin Heinz's blog