Long story short, I found that if you approach every conversation with a general attitude of honest service to the other party, then all will work out. Just be honest, forthright, and give good help, even in the sales part, and you’ll develop mutually beneficial relationships where both sides invest equally in the partnership. Steer away from abusive relationships where one side put in more than another.
The other trick is building a reputation in your field. You just need to openly share what you know regularly and be a presence in the tech community you want to serve. This will reinforce your commitment to serving your market and industry.
Good books on this topic
- The Trusted Advisor
- To Sell is Human
https://softwaredoug.com/blog/2020/12/22/hack-your-career-wi...
I have my own server for some hobby projects and I'd really want a plug and play solution for checking git-repos with docker-files and starting them with their own URL for different branches.
Right now, if I have 20 projects with 20 branches, that's 400 endpoints that needs to be configured.
And what's best practice with canary deployments via git.
So my question is, does it exist a solution and what should I search for besides CI/CD?
you can have branch-name, docker port and sub-domain as variable and define them at run time PS : Not the best solution, but could work for your use case
We're a boutique consultancy specialized in machine learning. Given the projects, our clients are exclusively large organizations. Repeat business is frequent and we amortize on the relationship we built with them. The clients are from the CEO leveraging his network.
During the past two years, we systematically refined our process to qualify prospects, properly onboard the client by making how we do business clear [what's ML, what it can do, what it can't do, what are the pre-requisites, necessity to have support from top management, necessity to have those we will build things for present at the table from day one, necessity to have a cadence and regular meetings to check progress and eliminate divergences as soon as possible not to build the wrong thing, getting requirements right, starting small with prototypes, getting to the job to be done and solving problems]. The people involved in a project are in the meeting on our side, and we nudge and insist that the people involved in the project, especially their domain experts and those who will use what we'll build be present. We have scars working only with executives insisting they knew best. We never want to build something that's not used, even if we're paid to do it. That's a waste of life.
We have ruthlessly and consistently refined this and we've generated more revenue with 6 people (and only three working on the projects) than we did with 17. The others are working on our product and we don't want to disturb them.
The product is our MLOps platform[2] that we use, precisely, to deliver value to our clients consistently and eliminate toil. Setting up environments (fresh collaborative notebook environments), scheduling long-running notebooks, experiment tracking, model deployment and monitoring, etc. This is the "abstract" section of the twitter thread: leveraging the experience curve of all the projects we have done in the past. Post-mortems on projects that have failed, why, how, when, etc.
- [0]: https://twitter.com/jugurthahadjar/status/131066829330549965...
- [1]: https://news.ycombinator.com/item?id=26075799
- [2]: https://iko.ai