Ask HN: Should we bring software dev in-house?

Fair enough. To clarify, my point was not necessarily “I know better”, but that it is incredibly difficult to get a broad view of the market from a single perspective. This market is by definition a chain of steps with parties that may be antagonistic. It is atypical in that way, and writing software in-house may be more difficult in this sector than in others because of it.

While writing software in-house gives you software better tailored to your exact situation it is at the cost of losing the overview of the business and the perspective of the parties you interact with. Whether that trade-off is worth it I’m probably pretty biased on, so take my stance with a grain of salt, but imo the business is intrinsically relatively ill suited for in-house dev considering the high degree of collab with other parties.

Apologies if it came off as arrogance, that was not what I was going for.

As an alternative you could appoint a software services business to build it for you, to your specifications, then they step back responsibly handing it off to your business. It's more expensive but they will be off your books in 6 to 12 months unlike if you hired your own team. You'd hire a small team to maintain the system, rather than a large one to build it.

Possibly dumb question:

How large is the company supplying the existing software? Can you just buy them, or even just that one team supporting the product line you need?

Want to second the two parent comments to this. Small freelance / contract team of very very senior very experienced people. 3 to 4 max.

I was fortunate in that I, for the first part of my career, joined teams that were structured like this.

Some additional thoughts:

- keep things small at the start - task your team with at least two goals for the first 90 to 180 days

       i ) to define a small but critical piece of work (actually designing and coding something related to what you need to do). Cannot be part of your core platform but will need to eventually be in the platform. Picking the right piece of work here is critical.

      ii ) to define a design, roadmap and project plan for completing everything you want done with cost, staffing, tech and effort estimates

Then use the 90 to 120 days and the two tasks above to evaluate:

    i) if the folks and team you have put together works:

        a) as a team and 

        b) with your existing business ( can they do the work, can they work effectively with the rest of your business, is the design the come up with solid and does it give you confidence that they can tackle the real core work you need done)


   ii) if you can get a sense of what it will cost (what did the 90 day project cost and was it delivered on time and budget per the team's estimate )

   iii) if the team can put together a road map with support of the business for the broader objective in parallel to executing the piece of work chosen

   iv ) if the solution if palatable from a cost perspective ( money, people, tech, disruption ) 

   v) if the staffing model , architecture and integration proposed for the project by your new team could work (get feedback from the rest of the business about what is proposed by your new team ) 

    vi) if your business can work with this new tech team ( feedback from your existing staff about the folks doing the work and their product for the small piece of work they tackled )

- It is really critical that they be 'senior' people - 'senior' here meaning they have done and seen a lot. The title will not tell you if they are. You have to actually look at what they have done. Look for senior free-lancers with a variety of (longish 4 to 5 years) experience using a variety of technologies (C / Java / PL-SQL / Perl / Rust / C++ whatever etc etc - but boring old tech is better, you will eliminate another variable from your project complexity ) in variety of industries / verticals ( 3 to 5 industries. This is a signal of effectiveness at learning new things and delivering effectively in new fields with new people in new environments.

- it is critical that your freelancers not just be developers: they have to be "business-goal oriented". Consider asking for references who are not developers and consider filtering your freelancer hires through their networks in LinkedIn - do they have a good mix of senior and non-senior people in their network who are NOT developers? That is a good indicator they worked effectively enough with other non-software parts of the business that the people on that side of the fence (marketing, ops, finance etc etc ) are comfortable being associated with them. Pick the areas that matter to you.

- Consider filtering for delivered results when you talk to candidates and in resumes: look for achievements / projects / work delivered rather than work done as this 'could' be a signal that the person is focused on actually 'owning' projects (not work ) and closing out on projects / goals (could also be a signal that the person did not not consider put delivered work in their resume so there is that - so, if you don't see it, just ask something like "what projects have you owned start to finish and how did you architect, design and execute on them" and interpret the response ).

- Key skills to look for in free lancers:

               - systems integration (making systems 'talk' to each other - you will have to make your existing system talk to your new system + you will eventually have to get your data off wherever it is now to your new environment and you will have to make the new system work with all the other tech systems you have now)

               - system architecture: designing software solutions

               - database architecture & design

               - project & program management 

               - lean six sigma / green belt ( means they have may have worked with ops people to optimize operations )

All the difficult stuff is going to happen in the background (batch processing, integration etc etc) so don't bother with front end development skills at the start - that is actually relatively easy to hire for.

You will definitely find folks who have the right profile who will work with you - the key is decent (not crazy) pay, benefits and elements of stability attached (contracted duration with pay guarantees for performance, performance bonuses if possible etc etc).

- Plan on developing a bench from the freelancers so hire some mid-level junior folks to work alongside them for when the freelancers inevitably move on. You will have to hire from outside (try and get mid-level people in the industry, not senior folks, so that it is clear that your senior freelancers are the leaders / owners of work ) but try really hard to source at least a few of these folks from existing staff if possible ( people in other job functions - and are good at those jobs - who are programming inclined ) as they are a good source of how things work to integrate into the team or as new hires. They do not have to be as as senior but they have to be able to keep up. These people start as grunts for your freelancers and learn the system as it is built - they are your future tech staffing.

- Plan ahead for what WILL go wrong. I strongly strongly strongly recommend reading two books

                - The Phoenix Project - https://www.amazon.ca/dp/0988262592
                - The Unicorn Project - https://www.amazon.ca/dp/1942788762

They deals with how executives and staff tackled a situation very similar to what you are dealing with and explains how to tackle some of the key structural problems you WILL run into. It is also a great resource for understanding how to run a project like this and understand how things could go right and more important, how things can go wrong and what to do WHEN they do go wrong (because they WILL ). The books will give you a very strong set of foundational thoughts about how to think about running this project if you decide to commit to doing it.

> The developers might be great, you might find you need to get rid of management dead wood.

In my experience great developers do not stick with mediocre managers, because they quickly find better options. My experience with poor managers is that they are only able to retain middling engineers.

> Or it might be that you get a very nimble team who in all likelihood have been itching to fix bugs for years and yet who haven't been able to due to competing interests in the business.

That would be closer to a win scenario, but I think OP would have had a strong feel about it - from the way they describe there interactions, it doesn't seem to be the case?