IME what works best getting new projects kick started is hiring a very small team of senior freelancers, making one of them lead, and letting them loose. I worked on such a team once and it was really excellent. The advantage of this strategy is if the experiment doesn't work out, terminating freelancers is much easier than permanent (I noted you're based in Europe).
Contrary to what other people said, I wouldn't try find a CTO straightaway. It's a hard role to hire for, especially at the start. I think you're better off unleashing a small, excellent team of builders then hire management later to help build out the team if the initial effort succeeds.
Happy to chat more about my experiences with this strategy, davedx@gmail.com (I'm in Europe too)
This is excellent advice but I would back up a few steps and do a few things before bringing in a freelancer team.
Identify a part of this system that can work somewhat in isolation and is non-critical if at all possible. Then document the requirements for this part thoroughly. This allows you to:
- Have something smaller for your new team to cut their teeth on.
- Ensure you have collected all the diffuse domain knowledge for this part in one place in the form of structured requirements.
- Forces you to think in terms of what you need and what is acceptable delivery,
If need be you can bring in a Senior/Staff level engineer to help you through this discovery and definition phase.
In my experience the most common difference between success and failure for a project often comes down to clear requirements and expectations. Your employees are the domain experts. You need to collect that expertise and document it in a way that this team can reasonably consume. This is difficult and time consuming so start now.
They will still have questions and get things wrong but this gives you a roadmap. They are going to be learning your industry while you are learning how to build software.
Best of luck
EDIT: formatting
A specific difficulty you are likely to face:
Your expert employees are busy doing their jobs. Writing requirements means taking attention away from that work - a difficult proposition, especially if they have managers who will ask why their KPIs are slipping.
Oh - you're so right. I see this probably around 20-25% of the time. Schedules slipping because you can't get time with the main SME.
would it be possible to just work on writing everything down and use all the time it takes?
I imagine the complicated part would grow wordy enough to stick out like a sore thumb.
Perhaps eventually have a freelancer turn it into technical documentation. The stuff we admire (if done right) but hate to do. (or in my case clueless how to)
(disclaimer: I know nothing, im just reading the comments.)
What is being expressed here is not a new problem. The challenge with solving it is that there isn't an easy set of steps that works every time. Someone's experience with the challenges of getting time with SMEs is highly dependent on the culture of the org, incentives, structure of the engagement, personality of the SME, actual workload, SMEs situation/feelings/stress, etc.
You can solve or mitigate these problems, but it takes experience and expertise that most coming from more pure software development backgrounds may not have. From experience, someone coming in with some consulting experience will tackle the situation differently.
Writing stuff down isn't always the best approach. Having a written record may be a good end goal. It may be better to have the small implementation soak up that experience through co-location with the experts. That way they are close by for interviews (probably too formal) but more likely sit and observe as the experts work. OP can then focus on building relationships between the experts and dev team. On this foundation you can add in more formality.
As part of the relationship management, OP will have to help the experts free time by working with their management. Without details of the company, we can't give real examples, but it might include supporting their requests for contractor support or giving their leadership political help.
When you can't come to some sort of co-location situation, you have seriously undermined your ability to execute the project. You will not have a true picture of the situation. Getting PMs or user experience people to engage with the experts will be lower value and require more clarifications. Developers can be low threat to the experts versus other types of people you can bring in.
These experts may also be hesitant to change.
It could be due to many different reasons. One the personal spectrum, they can overvalue themselves or have fear of loosing their jobs.
On the technical spectrum, they can be stuck in old tracks without computer knowledge and not thinking outside of the box. For example, in their eyes the objective is to move PDF file from directory A to directory B. In the ideal automated world, why is there a PDF in the first place? Basically "if you asked what they wanted they would have said faster horses...".
For the technical side, this is a part of what a good software engineering team should be teasing out from the verbal requirements. Check if the intermediate PDF is needed, if it is, it still shouldn't be part of the automation path, but instead serialize/send the data properly and output the PDF on the side.
Maybe a nit pick, but I would not accept the expert employees writing requirement documents that are "thrown over the wall" to the dev team.
You need personal access to talk to the experts anytime some question comes up. This means 1-2 experts work part time as PMs more or less, which will impact their regular work.
Costly, but I don't trust any other way.
I think there are variations of this. Yes, your experts need to give an amount of time to the effort. Making them a PM, in any sense of the word, is a step beyond contributing their expertise and can be avoided.
What you need is someone with significant dev experience, but enough outside exposure to step into the PM role. Ideally, it'd be someone with interest in user experience research, or a personality that connect outside of a dev team. They should be able to perform this role in a mechanical fashion to avoid a dedicated PM.
Doing this will be effective enough until things are at the point where a dedicated PM can be justified. If there is a struggle with the user experience aspects and getting knowledge out of the experts, you can get expertise from an agency on a short-term basis.
Adding a pure PM is going to significantly slow you down unless are one of the rare switchers who flip between dev, PM, and dev manager roles. People don't know what to make of these people, but they exist, especially in the freelance contract world. People will only full-time experience tend to look down on them because they can't understand it.
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
Then use the 90 to 120 days and the two tasks above to evaluate: - 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:
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
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.I've been going through a similar situation in a smaller company, and this is one of the best comments I've ever seen on HN.
Any given operation may not be able to follow all of it to the letter, but all of it is really sound advice and can be tweaked/customized for a variety of settings.
I'm probably thinking about this at a different level, but when I start something new I like to find the core pieces and the most difficult pieces and see if I can tackle those first. Everything else builds on top of that. I'm assuming you mean to start at a higher level piece that will need to use all of the lower level pieces. That's good too because it may help identify what those difficult core pieces even are that I'd like to go after first.
It’s a new team. This non-critical part is your shakeout cruise before heading off into the open ocean. You can identify how well you hired as well as how well you prepared for these contractors to begin work. Make appropriate calibrations or worst case scrap it and let the whole team go.
If they produce some big mess you will find out much quicker than if you set them loose on the big project. Small deliverables which incrementally get larger is how you roll on a new team. It allows you to get fast feedback and make small calibrations as you go. Hopefully avoiding the “fire them all” failed project scenario
Here you are just copying an existing system. Reverse engineering requirements from domain experts unnecessarily turns this into a green field project.
Genuine question: how do you suggest for that code to be maintained long-term if the original team was just freelancers?
If you do go this freelancer route I would assume that there will be no code to maintain long-term. The freelancers should be building a prototype, not something intended to last decades.
Either the freelancers work out and you begin hiring a permanent team (hopefully converting some freelancers to full-time) who will promptly rewrite / revise the prototype or you will go back to paying for software. Either way the prototype code should die or be taken over.
Is it common to build a prototype to throw away, and then actually throw it away and build the "real" thing? I've never seen that, ever, in 20+ years of software work. The prototype ends up being the long-term production version, for all its faults and weaknesses.
I don't think so sadly, even an iron willed CTO will have to risk a lot of c-level trust to justify rewriting something "that works" (at first glance).
Not my experience: freelancers have often built the initial versions of a product that have then become the permanent version. Even products that start as prototypes, if not total trash, often end up evolving into real software projects.
Why throw away software when you can iteratively improve and build on it? Unless the tech stack was wrong.
The artificial distinction between a prototype and a production system rarely survives reality in my experience. But that doesn't matter because the situation with long-term maintenance is not so different with freelancers doing the development to what you'd have to do with an in-house team.
It's rare for anyone to be around to look after the code they write for you forever. Ironically you might have more chance of a good long-term relationship with some of your freelancers - having a few good clients who come back to you from time to time is an excellent strategy as a freelancer.
So you always need the system and processes to be designed with future maintainability by other people in mind. Good developers will do that whether they're employed or freelance. Bad developers will mess it up either way too. Choose the people you work with wisely and try to make sure when you do bring in new people they have a good way to get up to speed so they can naturally take over as others leave. There's not much else you can really do.
Code is often written for an audience: yourself on a year, maybe a younger team member you have In mind. Knowing you won't be around to explain can help drive some decisions and write docs for the audience.
It’s can be less about code and more about supporting the evolution of the business process.
Acknowledge and incent the exit plan from the beginning
Incrementally, it might make sense to hire an independent audit on occasion. This might be hiring a senior to jump into the codebase for a week or two to see if they can make sense of it or see any glaring red flags. The important part is them knowing this will take place and them not knowing exactly when or by whom.
The important part is them knowing this will take place and them not knowing exactly when or by whom.
I recommend caution with this kind of approach. Even if you're bringing in a team of freelancers instead of hiring employees trust is still an essential foundation for the relationship. Clients who play silly games tend to get fired abruptly because it creates a toxic working relationship that isn't good for anyone involved.
You should be able to have an open and ongoing conversation with your team of freelancers about the long-term intentions for the system they are building for you and they should transparently and proactively work towards your goals without being nannied. If that's not happening then you don't need some kind of surprise audit - you need to find different freelancers who are on the same wavelength as you.
There is a whole class of hybrid incubator/vc firms in the US ("VC Studios") that have used this model and achieved success. Sometimes the model is inverted, in that the VC studio will build the MVP with their small, in-house engineering team before staffing the "real" company and eventually handing the codebase off to founding engineering team.
Consider where the company is right now - they're entirely reliant on a third party product that doesn't suit their needs. Every codebase is maintainable (to a certain extent), and the first step in getting a long term maintainable code base is... getting a code base.
Freelancers don't inherently write better or worse code than FTE's. Some of the most braindead, unreadable, undefendable code I've seen has been written by FTE's while contractors are leaving them in their dust.
The same way as with permanent employees. Agree on technical standards and documentation policies from the start. Build a good engineering culture.
Strongly agree here. It's hard to find a CTO if you don't have access to any engineering talent that you trust and have vetted. A small, focused project with a team of very senior freelancers both gives you a chance to dip your toes into the idea of running your own in-house software development, and an opportunity to vet individuals who can help you make good hiring decisions down the road.
If you're interested in following this strategy, don't hesitate to reach out to poetic.artifice@gmail.com -- I'd be happy to help on both fronts.
As for your concern about logistics being not sexy enough - I've found that the best programmers (and the ones you'd want) are more interested in the technical aspects of the problem and business and customer impact, rather than the sexiness of the business domain.
Just want to heartily agree with this point here. Certainly many of us do get excited about particular business domains from time to time, but in my own experience, I get more excited about technical challenges, and -- critically -- solving real problems for real customers that I can see first- or nearly-first-hand. The customers for this "product" would be internal to OP's org, so the people who end up building this would have front-row seats to how it's being used, what's good, what's bad, etc.
For me red flag is that for OP as a developer I will end up being a cost.
Even with all the good words he wrote how company can improve by doing own dev - reality is that company makes money in logistics and as a software dev I would be second class citizen and cost center.
That is why I much rather work in company that makes money on software, because here I am money making.
Everyone’s a cost. The myth of revenue centres was made up by sales & marketing.
Well I do agree everyone is a cost.
But it still doesn’t make company dynamics not true. Logistics company will have bunch of logistics specialists as management and they will see it as revenue center and will see „their own kind of people” as more important.
The management sets the company dynamics to whatever they want.
That idea of costs and profit centers is bullshit that only bad manager believe in. It may or may not be the case with the one company of the OP, we don't nearly enough information to judge.
(But the fact that the OP is reaching into IT with the goal of improving their people's productivity is a very weak indication that they are better than that.)
Yes so I am indirectly replying to OP question if he will be able attract and retain tech talent and I cannot imply anything really about his specific company.
I am only pointing out my view on it based on my years of experience working in different companies. Looking by up votes it seems my experience to be applicable for other people as well, so I guess it might be useful for the OP.
Funny that sales and marketing sells and markets itself.
> company makes money in logistics and as a software dev I would be second class citizen and cost center
If software can make the company provide better logistics more efficiently, it's not a cost center, it's an enabler. It pays for itself in reduced costs and increased revenue.
A cost centre is, by definition, somewhere that only produces costs and is never attributed with any revenue or profit.
A smart management team can figure out that investing in IT, Software, etc is going to have a positive ROI overall by increasing efficiency among other things.
Unfortunately my experience (and many others') is that only the balance sheet will be considered and the goal will always be to reduce the costs in cost centres as much as possible.
Even in a company that doesn't fall fully into that trap, often times a lot of effort needs to be expended to keep funding at current levels, never mind the rituals involved in getting increased funding for new projects, hardware, staff, etc.
Generally the more obvious the connection between your work and company revenue, the easier your life will be.
> A cost centre is, by definition, somewhere that only produces costs and is never attributed with any revenue or profit.
Which means that if investing in IT is an enabler for gaining revenue or profit, it's not a cost center by this definition--it's necessary to gain revenue or profit. As you note, many companies don't appear to be smart enough to see this, but that doesn't make it wrong.
It's possible to treat software close to a first-class citizen even technically as a cost center. Probably the key is to have a lean team that is effective and management trusts, in a business whose profit margin or stability can be greatly enhanced by good software. If you're relatively lean then nobody sane would be looking to cut fat in your team. On top of that, the attitude of management and the culture is really important, and this CEO's attitude is at least a good start.
I hear Meta Ads has one of the more toxic environments for SWEs, even though Ads make money.
I'm gonna go against this heavily tbh:
If you don't have a 'trusted wrangler' freelancers won't build anything worthwhile as they're not interested in the long term unless forced.
There must be somebody you know, or friend of friend, to get a warm intro to an experienced developer you can pay to oversee said team on an interim basis. No consultants, agencies etc. they'll fleece a non-tech like you, save your money and drop it on somebody good who can actually help execute your vision.
If you don't have a 'trusted wrangler' freelancers won't build anything worthwhile as they're not interested in the long term unless forced.
Freelancers' careers live or die based on where future work is coming from. Happy clients are good for repeat business. Happy clients refer other potential clients. Happy clients are good for portfolios or case studies. Smart freelancers are all about keeping their clients happy in the long term. It's just good business.
Of course there are people in the freelance world who are hopeless and will never build anything useful just like there are people in the employment world with the same problem. But it's much more career-endangering to be incompetent as a developer and/or as a communicator in the freelance world because freelance gigs can often be terminated relatively easily if the client isn't happy with the work.
Maybe this is different in the parts of the US where compensation for tech employees can be way higher than anywhere else but in most of the world freelancers tend to be relatively good at what they do and part of the attraction of going the freelance route is that it doesn't have the glass ceiling on compensation that being an employee often does so if you're good enough to justify higher fees then you can actually charge what you're worth.
Not a freelancer, but this is a classic "market for lemons" situation: designing things for the long term takes a significant amount of extra thought and expertise. If two freelancers give two different quotes, one of which has a higher hourly rate and will take a longer time, there are one of two possibilities:
1. The more expensive quote is way overpriced, trying to extract money out of the buyer and possibly double-dip
2. The cheaper one is a low-quality "cowboy" job that's going to cost way more to maintain in the long run
If buyers in general can't tell the difference, then the market will end up pressuring even the high quality people to cut corners and produce "cowboy" jobs. In other words, it may not be 100% the freelancer's fault they're "not interested in the long term unless forced".
So part of the job of a "wrangler" is to understand what's worth investing in and what's not -- to know that it's worth spending double in this particular area because it's a long-term win -- and to be able to evaluate the output of the work, to make sure that what was delivered actually is higher value.
My experience as an in-house dev working together with freelancers and body shops (in Europe) is less positive.
A pattern I commonly see is that they are heavily technology focused and don't really care about the domain, because domain-specific skills are not transferable. They are snake-oil salesmen, every problem can be solved by adopting some hot new piece of technology which can be added to their CV and increase their market value. What's frustrating is that their contribution is in the end often negative rather than merely zero - adopting over-architected solutions looking good on CV will result in great costs. If you have a strong technical leadership, you can catch their bullshit, but in the op's situation, they would be pretty much relying on freelancers' good will and abilities without much of a chance to verify their claims.
To be fair, I've met also a number of very good freelancers, usually staying with the company for years.
This same danger exists also with the normal employees, but I think this "pad the CV, move on" is more common in freelancers since they generally operate on shorter timescales.
In practice this simply doesn’t pan out. There are many many terrible freelancers out there. And without someone technical in-house vetting their work, you’ll have no choice but to judge their based on their output. This is a huge problem.
Software needs to be designed with an understanding of the business needs and goals. You need someone who understands how to keep the software well designed (ie. Easy to debug, update and extend in the future).
Judging solely as a user of the software gives you no insight into whether or not a plate of spaghetti code could be holding behind the scenes.
Good code has two traits: It does the job it was designed to do. It is easy to update and maintain.
Everything else you read online is nonsense. And you need someone trusted inside your company to ensure the second trait is being adhered to.
I work for a small company, around 10 devs. We've picked up quite a few projects over the years where a freelance team came in, built something and when the going got tough, walked away. That said, I've seen the same happen at renowned companies, so perhaps it's just an issue of generally people taking advantage of the shortage in experienced devs. I would aim to get some longer term stability, either by working with a company you trust through your network, or engage a tech Lead/CTO for a longer term who can oversee the contractors.
I've worked as a freelancer for a while, and have often worked with mixes of freelancers, permanent employees and everything in between.
I think there's a big difference between bringing on a boutique consulting shop and hiring freelancers who sit together in your office. The sense of ownership and professional responsibility is way higher in the latter case. In fact I'd even go as far to say that many freelancers have MORE professional pride than permanent employees, many of whom just want to draw a paycheck and live their life.
YMMV of course!
Having had the fun of taking over a project from a bunch of clever contractors I would caution: It may be too clever. There is value in simplicity and a stake in long term ownership. Some article here recently associated technical debt as lost institutional knowledge so handing the most key decisions to contractors has also drawbacks. One needs an integrated approach for design, build, maintenance and operation.
Mixed in with this may also be architectural decisions based from a "let's just spin something up quickly" mentality. Those foundational architectural decisions have a way of becoming set in stone, long after the freelancers have left, dooming the project to scalability and latency problems which seem to linger forever.
That, plus "they're probably going to fire us in a year anyway, who cares" thinking
And "we don't need to understand the business domain, let's just MVP", which they get away with because they would get accused of not being agile if they did boring stuff like trying to understand the business
I refer more to bigger off shore consultancy shops than individual freelancers
I've seen equally many projects never achieve lift-off because they were stuck in analysis paralysis trying to architect MVP for scalability, extensibility etc.
And even if that succeeded you often end up with fear of change because the complicated architecture can't be touched.
It's really important to have the right balance here, but KISS and YAGNI are often easier to scale when you need it, than the reverse. If you don't have the mentality that the MVP must never be rewritten.
Yes! This also happened in the team I mentioned. Sometimes during design/architecture meetings we'd run into the "too many chiefs" problem. That's why I think it's also important to make clear who the lead is from day one.
Agreed. Take long term ownership. Don't farm this out. There are some companies out there that provide support and consulting on open source projects. Rather than look for a freelancer to build an in-house application, find someone that can help you capitalize on tools that already exist.
My company does exactly this. We build and maintain an open source project (SpiffWorkflow, for process automation) and help our clients build internal skills to deploy it and use it. No license fees or SAAS lockin - and no team of developers that walk out the door when things get difficult.
As a developer who became this kind of a CTO a decade, maybe two before it became fashionable, I would have agreed with this in the past until I learned why otherwise with companies this size.
All the devs in this comments can do what I share below. 1000%. It’s a different way to make an impact and help make healthier spaces for technical teams to do what they want.
I’ll share one example. Clever architecture and leverage can beat most coding especially in the B2B space. I find I am fast at both architecting and uncovering useful system integration paths for the short and long term along with the flexibility in mind.
That being said, I have also seen a team of 100 devs flown in to write an ERP from scratch and it worked too because the process was fixed.
I won’t rule out a world beating team where 5-10 senior devs can beat a team of 50-100. I have got to be a part of those kinds of teams and also lead them. The caveat is being able to deliver world beating stuff is different than aspiring to it as well. It’s just not always sustainable way to live.
Since A company usually sells to companies the same size or larger. Anyone who comes from scratch can have their goose cooked pretty quick when a new client demand a different level of scrutiny in systems and data if coding from scratch.
Having deep enough experience to poke my head out in this thread both on my own as IC leading the charge, or or taking in my team, the orchestration of internal and third party vendors and resources is a big part of this. I deeply believe in external vendors operating in a client side platform I help implement and leave them with training that works.
A technically functional CTO who is still technical en putty to simplify and leverage to help deliver impact helps bring in different kinds of architectural and framework approaches.
I loving call it what management consultants talk about it don’t do. I’ve made learning and implementing that my craft to leverage solutions for anyone I put my time towards. It’s a life changer. Everyone wants the kinds of devs on YC to help their companies if they can learn a little bit of business.
It works well enough that I don’t need to pursue a public profile (although that is not changing), and warm introductions are a reality.
I share this because it’s possible for anyone who wants it instead of downplaying it. I help clear the path for the doers and builders, as one.
You have a fair indirect point that there’s a lot of different kinds of CTOs too.
If a business wants steady operation while switching over it will ultimately place a heavier loads on their teams.
If a business wants capacity to operate more smoothly to either grow capacity or increase flexibility for other things with their existing workforce.
This kind of thing may not always be built to success with the number of surprises and landmines discovered along the way.
Part of a transformation can become agile, parts of it water fall, all while holding the business and staff increasingly hostage while deciding to do a big bang switch over or daring to run in parallel.
Lots of people side things come up as well when changes happens to them instead of with them. It’s not uncommon for subject matter experts choose not to share information what itself can take some time.
OMG. GPT? Claude?
Nope, just me, I promise.
It could have been shorter as it's not my target audience, not really able to edit it now.
Not even sure they can come up with a word soup that thick.
Nope, those usually get basic grammar right.
Good freelancers are expensive and don't stick around long-term.
That's fine; this would be an experiment, after all. If it goes well, those freelancers can be tasked to help hire a more permanent team, and/or be offered permanent positions, if they're interested.
It depends! I've probably stuck around longer term more often than not. You can also write contracts that enforce the term if you want. Agree on things like this up front.
Good freelancers are expensive because they know the value they provide. In this sort of situation you tend to get what you pay for.
I don't know why you think they won't stick around long-term. I've seen many freelancers maintain relationships with clients for a decade or more - not necessarily full-time as if they were employees of course but with a genuine connection and coming back to do more work with the same client from time to time. If you want to retain access to the knowledge and insights of your early developers but also want to bring things more in-house - often because you don't need an all-star team to do every little thing once the system is in production and hiring a more mixed team is sensible financially - then this kind of occasional recurring contact can work well for everyone.
My caution is at the end of working with free lancers you have no technical retention.
My company worked with freelancers/consultants for years, it just delayed the inevitable. You need to start building your in house team.
Find the ONE. See if he can build anything on their own. If they can/thinking is good, then scaling with freelancers seems good because you retain knowledge and long-term vision/oversight.
That's the whole point - at this point they don't know if they want to build out a full team. Start small and measure progress, you can always add permanent employees along the way. (We did this too)
Excellent advice - this matches exactly with my experience. Get a core team of very senior freelancers and let them run it as a parallel project. You don't need a huge team (2-5) but you do need quality and people who can work together.
Quality isn't always easy to find - avoid agencies, hire the kind of freelancer who dares to work on complex / hard projects (there aren't that many of them) and ideally.
The pitfalls are mainly hiring:
a) Inexperienced people who happen to work for themselves. b) Agencies, they have an incentive to sell bodies: two mid-level bodies are 1.5-1.8x the cost of 1 senior and they do less work. Especially if they sell you a team of them.
Pick a small vertical slice or process and have them implement that. Run in parallel (the costs in these projects is when operations are negatively affected). Treat it as a learning process. Iterate. Then grow based on what you learn.
Oh and whatever you do, don't hire anyone who is a "scrum master" or "project manager" - if you're hiring from the top you won't need that; people like us are highly professional/communicative/focused. Having someone come in to "take charge" is a bad idea.
I'll disagree with Dave on one thing: I personally prefer not having a single lead developer. I've come to appreciate the advantage of having multiple, aligned leaders in a team. Teams like that are absolutely awesome to work on and you can specifically hire for it.
You will absolutely need buy-in from your company, you'll need to give them access to the people doing the job and likely have one of your senior employees do the job. Based on my experience the best internal people are the same people who you'll be putting through a management development program - the type where they get to know the entire business. They'll have the right attitude (can-do, hard workers, personable) and ideally are good with people / nice to work with.
Have the team as a whole report to you. It's a small team (3-4 devs + 1 internal full time).
Also make sure that the team are in control of their own destiny. You'll need backend/frontend/ops/dev-ops skills covered in that team, you don't want them crying for the sake of having a server made available for them. Give them an AWS / Azure account and let them work there.
If you take this route OP, I hope that you'll ensure the freelancers are in person and on site. It's much easier for them to build the right software if they can sit next to the users.
I’ve been on one of these teams and we accomplished pretty amazing stuff in a short time span. Keeping the team lean and senior, ensuring we each had a specialization yet broad enough skills to interact and collaborate well, and providing us with agency to make decisions was a magic recipe.
I’d love to do that again. It was by far the most fun I’ve had working on software. These days I do pretty boring work that’s significantly below my capabilities, but it pays the bills and there’s not much else to pick from at the moment.
As for if someone hypothetically did choose to build a new solution in this scenario, it would almost certainly make sense to build it in tandem with your existing process. Going totally greenfield and trying to port your business over in 6 months would be misery. I’d look at ways to incrementally build a new system which you adopt gradually, probably starting with replacing the no/low code pieces you’ve already built.
Any kind of monolithic approach to replacing an existing system gives me deep, deep tingly creeps due to past disasters.
+1 to this take. I think hiring a CTO at the start might lead to its own distinct challenges, especially if that's not something familiar. Hiring a small excellent team of builders could be an effective solution, especially folks with sufficient experience and very strong communication skills.
As a freelancer doing exactly this for nearly a decade now I wholeheartedly agree. Freelancers also tend to know other freelancers who are used to laying the tracks while the train is running, and can usually get a high quality team together real quickly. Downsides are that you don't really retain any of the expertise in-house, unless you also staff up internally and do a proper handover.
Agree with the general approach, whether the devs are contractors or employees. In my industry we might call this a Skunk Works project. Get a small, talented team and turn them loose on a focused problem. If they make fantastic progress, great, if not, at least it wasn't a huge expenditure.
Great advice, perhaps I can share some personal experience.
I had a similar experience working with a large agricultural company, where we developed a track-and-trace system to manage their entire workflow. This system provided them with insights into all aspects of their processes. They gained full insight into their margins, mass-balance and quality control, from field to fork.
Our agreement included the agreement that we would own the system, with the option to eventually resell the system in the market, ensuring we could establish a company to support the system after development was completed. As you don't want to loose the knowledge after the system is finished and don't want to have a complete team of developers on your payroll.
We only developed the components that were crucial to the business process, relying on existing software packages, such as the accounting system, and ensured seamless integration between them.
One approach that worked really well for us was working on-site and providing support to the people using the system. This was invaluable in resolving issues that users were experiencing, and it also kept us focused on delivering quality—otherwise, we would be the ones responsible for providing support.
Please note that if you begin development, don’t expect the first version to be the final one. This was a major pitfall for us. The first version was good but not future-proof. Only after developing the second version, essentially a complete redesign and redeveloped from scratch, did we achieve the best solution for the business.
Ensure you maintain an open dialogue with the development team and allow for quick iterations. For us, a significant challenge was aligning expectations. Budgets were tight, and expectations were high, which created a high-pressure environment, that worked great for us and helped us focus. However sometimes this led to a lack of appreciation for our work, as expectations where not met. Keep in mind that developers think differently from business owners. We addressed this by having a technically proficient, data-savvy production manager in the company who understood most of our challenges and helped realign expectations.
Unfortunately for us, the company we built this system with didn’t respect our contract, preventing us from distributing the system and killing future opportunities. This resulted in legal action, which didn’t end well for us, as the company was much larger. We were naive in thinking we could make it work, assuming it would be in the best interest of both parties, but they didn't share the same intention.
Yup. My consultancy is this- collective of very senior folks who have worked together for years, with experience in most business domains, most tech stacks, and most compliance regimes. This is what we do- accelerate the transition from either internal legacy or external dependency onto new solidly architected appropriate/ergonomic stack for internal team to maintain/extend. You can't hire the experience to get you started in the right way. We leave once you are transitioned because you don't need to pay premium to operate. Feel free also to reach out, email in profile.
I do this kind of work in Europe as a freelancer since 25 years. I really enjoy it because technology is not an end in itself for me, but a tool to help companies to work better.
Did you find freelancers are motivated to really learn the business like an employee (hopefully) would? In my experience of having freelancers/contracters on the team they learn things in a very shallow way, just enough to get things working. They also aren't often motivated to make things easy to maintain because they know they won't be the ones maintaining it.
This is a great set of suggestions. I've been on just such teams (and led them as well) and the way it went for us was:
- small team hired (via a well regarded agency) - small team creates and releases initial, limited POC - company retains the freelance lead to staff up an in-house team - in-house team takes over and starts moving to a more complex phase 2 product - initial project ends up being maintained by an offshore team while in-house team goes gangbusters on everything else the company needs.
We had a freelance team for each major product (web, iOS native and Android native). In house teams existed for backend and devops but freelancers create all of the customer facing products for at least phase 1.
It was useful to have an architect level person involved at the start but once development was moving everyone had enough experience to make the need for a higher level tech person a non-issue (the freelancers ranged from senior dev level to architect level). It helped to have someone in-house overseeing things (timelines, scope, etc.), of course, but someone at the CTO level would have probably not moved the needle much in that first year of work.
The "move fast, break stuff" phase benefited from a small crew of experienced devs without too much bureaucracy while later phases needed more structure.
Agree with this advice. Our consulting agency, also based in Europe, specializes in exactly this - bootstrapping software solutions for companies that lack the in-house experience to do so. After a successful launch our clients usually transition to hiring employees to take over our work - a transition we actively support. It works out quite well in our experience. (contact/website is in my profile if interested)
This is good advice, and a way to test the feasibility of bringing the work in house.
Probably the best way to think about this whole project is not as a project, but as a capability to grow internally. As a big project, you'll get stuck at 80% and never deliver. If you start small and deliver continuously, you'll get stuck at reducing the pain by 80%, which is probably a huge win.
Software is grown. Start small and focus on delivering value quickly to build momentum and credibility, but make sure that the team lead knows that your vision is to eventually replace the other systems.
Im a product designer who loves these types of roles the most. Im biased obviously but having a designer work with the dev team speeds up results as you will have someone focused on identifying prioritizing and solving important problems for the team.
Agreed. The important thing is the senior part. Find and pay the hefty premium for a small, experienced team. The code quality questions, etc are answered by that.
The approach of "I'm going to hire someone to build me a team" only works if you know someone excellent. It is a very low percentage strategy if hire #1 is from the market.
That doesn't mean you can't find excellent people through the market, but you'll have to see them work first, and it might take a few tries. You won't be able to spin up your own interview funnel and get good results. Hiring freelancers and seeing who gets it is probably the only way your organization can reliably detect talent (whereas a software company would have an interview funnel as a core competency). Once you have a freelancer who gets it, you can ask them if they want to join, or if they want to get paid to interview for you. Talent likes to work with talent, and the freelancer will be better at interviewing than you. Repeat this process until you have a team.
Eventually you may want management, but by the time you need management, you should have a pool of engineers large enough that one of them would be willing and able to manage the rest. They will be more competent than any manager you try to hire from the market by a mile.