3 ms·

I’m part of a 20-person company that was in a similar situation. We have since built our software in-house, replacing the software we previously struggled with,

I’m part of a 20-person company that was in a similar situation. We have since built our software in-house, replacing the software we previously struggled with, and it’s worked out even better than I originally hoped because it felt so audacious at the time. One thing I think is key is making sure that whoever is leading this project (the lead developer, not just the person they’re reporting to) needs to know the business cold. They should spend serious time learning the roles of the people who will be using the software so they can design it well to solve the problems those roles face. I lead the development for us, and I attribute most of the software’s success to simply having spent so much time in so many roles in the company. It’s that cross-section of knowledge that makes all the difference.

samstave 2y ago
However the problem domain that this fellow has 'Logistics' Can be a big scape, but more importantly the nature of the logistics is important whereas "shipping logistics for a parcel" is a hell of a lot different than logistics with specialized compliance, handling, security, discretion, coordination-of-other-entities, does. It would be interesting to know what niche is ~$300-400 million ARR thats being handled by 3rd party contracted infra? --- However, having worked as a high-paid consultant on high ticket/visibility/risk projects -- HN is giving some great advice. (hire and empower a great lead - allow a new approach. Ivolve your staff and have what you need built. Continue to work with the external that you have, and as a requirement (where appropriate - have them respond to your lead on any questions your lead comes up with)
TehShrike 2y ago
I'm not sure they necessarily need to know it cold at the start, but they do need to have access to someone who knows the business cold, and they need to care a lot and be willing to dive into the business details.
- oaiey 2y ago
  Understanding the domain is mission critical for projects. As the lead/architect/PO/... You need to balance what stakeholder say and what the really need. You can not get that, if you do not know the domain. This is all DDD play book.
- marcosdumay 2y ago
  > but they do need to have access to someone who knows the business cold Yes. Very close access, to the point where that someone will spend almost as much time working on the software as the software developer.
  - TehShrike 2y ago
    For sure. Ideally you should be able to talk with them at depth about schema design.
th3byrdm4n 2y ago
Second this. Cross functional knowledge is the secret sauce of in-house designed software. Nothing off the shelf does that. Integration is where cross departmental solutions live and that’s an underrated nightmare
- Too 2y ago
  Third this. If the software team (at least the lead) does not know the business requirements, you are not doing in-house development. Otherwise, it is just equivalent to off shore development, that happens to sit in the same building as yourself.
  - RaftPeople 2y ago
    Fourth this. Other than making sure you find the right person/people from a raw skills+personality/capability perspective, it's the next most critical item.

samstave 2y ago

However the problem domain that this fellow has 'Logistics' Can be a big scape, but more importantly the nature of the logistics is important whereas "shipping logistics for a parcel" is a hell of a lot different than logistics with specialized compliance, handling, security, discretion, coordination-of-other-entities, does. It would be interesting to know what niche is ~$300-400 million ARR thats being handled by 3rd party contracted infra? --- However, having worked as a high-paid consultant on high ticket/visibility/risk projects -- HN is giving some great advice. (hire and empower a great lead - allow a new approach. Ivolve your staff and have what you need built. Continue to work with the external that you have, and as a requirement (where appropriate - have them respond to your lead on any questions your lead comes up with)

TehShrike 2y ago

I'm not sure they necessarily need to know it cold at the start, but they do need to have access to someone who knows the business cold, and they need to care a lot and be willing to dive into the business details.

oaiey 2y ago
Understanding the domain is mission critical for projects. As the lead/architect/PO/... You need to balance what stakeholder say and what the really need. You can not get that, if you do not know the domain. This is all DDD play book.
marcosdumay 2y ago
> but they do need to have access to someone who knows the business cold Yes. Very close access, to the point where that someone will spend almost as much time working on the software as the software developer.
- TehShrike 2y ago
  For sure. Ideally you should be able to talk with them at depth about schema design.

th3byrdm4n 2y ago

Second this. Cross functional knowledge is the secret sauce of in-house designed software. Nothing off the shelf does that. Integration is where cross departmental solutions live and that’s an underrated nightmare

Too 2y ago
Third this. If the software team (at least the lead) does not know the business requirements, you are not doing in-house development. Otherwise, it is just equivalent to off shore development, that happens to sit in the same building as yourself.
- RaftPeople 2y ago
  Fourth this. Other than making sure you find the right person/people from a raw skills+personality/capability perspective, it's the next most critical item.