Wouldn't that mean that all your web traffic is going through a google server?
1,339 karma · joined April 13, 2011
In your case he just needs to hire "coordinators" that coordinate the work and quotation and have some P&L bonus.
In construction, former architects are great for this type of role
Looking for somebody who has experience with AWS device farm and Appium to help us setup real-device testing
Feel free to reach me on nicolas at horizon65 dot com
If you, on the contrary, invest ridiculous amounts of time in user research and only build things that are validated then waterfall is fine.
If there is a theoretical model for ambient temperature superconductivity, then that should help us zoom in on potential materials that could be an actual superconductor someday?
The justice system is designed to defend the innocent, not to aggressively pursue and harass the guilty.
SBF's is living on borrowed time as the cases make it through the legal process.
Compression algorithms detect recurring blocks and remove them with a special symbol and I think the shortest path would be uncompressable with compression algorithms.
- Meeting activity tracking
Meeting scheduling is kind of covered now but meeting activity tracking in CRM's hasn't caught up.
Also these types of calls and call activity is unrecorded now
This issue got worse since video calling is often the default
As a former CTO, almost every product I worked on had a request coming in at some point to create an internal CRM and I do believe in embedded CRMs as a software category.
There are even SaaS categories that could use some CRM-like ability (e.g. link building tools, procurement tools, debt collection, ...)
Open-source would be a good fit for that model cause you could take it in-house if you need a lot of customizations.
Some painful CRM issues I encountered:
- Pregnant funnels
when sales sets up the funnel stages in a way that leads can go back through the stages (e.g. "next meeting scheduled", "follow-up" or "offer sent") so a deal passes through the same funnel steps several times.
Not sure there is much you can do about that except for dynamically creating more stages in the funnel
- Last-stage-changed-at
Another issue is that CRMs don't keep event logs of what actually happened and just keep the last stage and when you changed that stage; this makes it impossible to analyze stage-durations and correct for cyclical stage switching (see pregnant funnel problem)
- Call quality
You would think that in 2023 voice-over-IP would be super reliable and works every time but I can guarantee you that in a 30 people sales team you will have many! complaints about call quality if you only rely on VOIP.
Always have the ability to call the salespersons' real phone number (over the traditional telco network) and then call the client once the sales person is connected. (a sort of conference call).
This kills all call quality issues as there is a fallback to dedicated phone networks.
- Call activity recording
Call activity recording is actually very important because apart from pipeline reviews, tracking sales call activity is one of the only leading predictors of sales success (it also catches lazy sales ppl).
Related to the above, some CRM's are able to record the calls with VoiP but fail to do so when real phone networks are involved.
- Cell phone masking
When using CRM calls, in hubspot and zendesk you can spoof the phone number; this is typically set to the salespersons' cell phone so the client can call back but when the client calls back the call goes unrecorded.
- Lack of IVR menus
IVR is a part of every PBX setup but they almost never play nice with CRMs; only Aircall integrates IVR menus but it relies only on VoiP and was a huge nightmare (see call quality issues).
- Treating leads and deals as separate records
It's surprisingly hard to build funnels that go from "this person filled in this field and has these UTMs parameters" to "which UTM parameter made actual money because almost all CRMs have a dual LEAD/DEAL record.
They typically destroy the lead and it becomes a contact which often has no stages anymore.
Nobody in Sales and marketing thinks about it that way though, it's more "here's a lead and then the lead progressively discloses more information"
I always think the best datamodel for a CRM is an event-sourced log with a giant json blob representing the latest stage that can be rebuilt from the event-source log.
- Outbound email chains
Most CRMs use their own email address and the main company domain to chase prospects (and setup automated email chains), which as you can expect sometimes get spam-listed; the ability to email through a separate domain and to capture replies properly is needed.
My current solution is to just ban the use of automated email chains but I've seen other companies use mailgun to create a proxied salesperson' inbox.
- Closing the loop with marketing
Google analytics and facebook has tags you can use to indicate the actual deal value of the generated lead. You can say this click led to 1k in revenue; except it's a huge pain in the ass to do this because of the lead/deal breakup and often the original contact details change as the sales person gains more trust.
Another option would be to export events to analytics tools like Amplitude so you can get a complete marketing-product-sales funnel
The reality is you will make mistakes, even if you are the best programmer in the world.
You can shift your mindset and accept that you are making mistakes which you are blind to see and then get feedback as early and often as possible to deliver a better outcome.
Now I welcome any type of feedback, regardless of the tone because you can think about it and fix it if it needs fixing.
Anything worth building requires multiple iterations to get right.
Adopting this attitude will also help you in the workplace because people love to work with people that take nothing personal.
You can email me at nicolas@horizon65.com
Private Pension is a leading provider of retirement solutions in Germany. We help individuals plan for their future and achieve their retirement goals through our customizable pension plans. Our team of experts is dedicated to helping our clients navigate the complex landscape of retirement planning and maximize their retirement income.
Join our team and help us make a difference in the lives of millions of Germans who are planning for their retirement.
There is a longitudinal study on PTSD cases that investigated why only 35% of people suffer PTSD while some of their colleagues go to similar events and while going through trauma processing, bounce back after some time.
The main finding was that many of them found helpful frames of references to manage their feelings around trauma (often along the lines of... the guy next to me was worse off, at least I am alive) and that allowed them to go into post-trauma growth.
Assigning present-day problems to old events is just a very common way for people to take on a victim mentality and avoid dealing with what is in front of them.
Thinking you are a victim is also highly addictive because it shifts responsibilities from you to something that is not-you (parents, boss, partner, society, your gender, racists, ...)
While not all circumstances are your choice, at a fundamental level remaining a victim is a choice.
There's always somebody worse off than you.
Anyway, aren't they doing address verification with snail mail nowadays?
Having it all together is perfect for code re-use and testability.
It's also very easy to know if you broke the bigger picture while working on a subsystem of the monolith because the test-suite will tell you.
In my humble opinion, monoliths are unpopular because not much thought went into the original design of the code and as a consequence there are large chunks of technical debt interfering with everybody's work. It certainly doesn't help that many popular frameworks don't give you the design architecture to grow big apps.
But the good news is that if you don't split your teams, you also have more engineers on hand to refactor the codebase to be more manageable.
Once your team loses the rapid feedback of "did this break user-facing functionality yes/no?" your reliability and speed of shipping features deteriorates rapidly as now most engineers will start to fear shipping to production.
Ideally, you break the team into subteams and follow the natural fault-lines in the codebase. Most codebases have areas that do not interact much (or not at all) with each other and they lend themselves well to assigning to a specific subteam.
I'm sure there's a point where this breaks also but I haven't reached it yet.
That's assuming good intent, worse intent is that devs want to experiment with different languages or generally want to avoid learning what everything is in the codebase or they are unable to use their editor properly to navigate large codebases efficiently.
There is absolutely no reason to split the codebase and subsequently the test-suite ever.
You can always take a monolith codebase and deploy it differently with the configuration driven by environment variables. (e.g. external vs. internal API's). This way your test-suite remains unified and can test the entire application.
1/ Hydrogen cars and trucks exist but they break down a lot and they are not mass produced. There is no infrastructure to repair them either.
The investor is funding repair points and fuel points but the route has to be carefully planned to make sure the vehicle arrives to those points
2/ Hydrogen fuel distribution is almost non-existent at the moment (which was the main focus of this investor) and they were looking at building distribution points along the major road networks
It's a problem that electric cars don't face as electricity is already everywhere.
In the short term, only islands or otherwise very isolated road networks may convert to hydrogen fuel. And that's optimistic.
First off, young kids (<6) need parenting attention. If you want to go hardcore working side-projects and a fulltime job OR more than fulltime without income then that's going to push a lot of the work to your wife. Even if she's fine with it, usually your kids aren't. After 6 it gets easier.
Second, founders that have investment do get a salary so it's not impossible. However, the fundraising climate just collapsed and it is harder to fundraise today.
Third, it's not really necessary to build technology to fundraise though.. what's more important is to convince the investor that there is a genuine need for what you are building and that you have a team that can get it in the customers hands.
The best way to do that is with data from potential user interviews backed up by clickable prototypes of the product.
You don't actually have to quit your job to work with designers and conduct user research to figure out what you're thinking of building makes sense and it's trivially cheap to hire user testers online.
Talking to potential users and building out the prototypes is not a fulltime job. From there the insights alone should be enough to convince your wife, angels or accelerators to take a risk on you to build it. VC's will only come when you have graphs going up into the right.
So yes, keep it a side hustle but don't program anything... iterate on prototypes instead.
Crypto's real future is in machine-readable accounting imo
The other option is to just fire him and then explain that you've been given feedback to him for a while and that you've had enough and that letting him vest would just be plain unfair to people who do put in the work.
Depending on the size of his grant, your current and future investors will think you are weak for letting him vest. That's also a conversation you don't want to have.
A strategy you can use is to incorporate any refactor into the estimates for a "new feature" development with the idea being that if you have to touch this part of the codebase that it gets refactored.
In this case since there's no framework I suggest to have a framework gradually take over the functionality of the monolith and the fact all the routes are in nginx will actually help you here because you can just redirect the route to the new framework when the functionality is refactored and ported into the new framework.
Do not refactor the database as interoperability between the legacy project and the new project can fail although migrations should be executed in the new project.
What I do suggest is to get development, staging, pre-production and production environments going because you will have to write a lot of pure selenium tests to validate that you didn't break important features and that you did correctly recreate/support the expected functionality.
You can run these validation tests against a pre-production environment with a copy of production. This also gives you feedback if your migrations worked.
On the team, that's the hard part. If they walk out on you, you will lose all context of how this thing worked.
As precaution, get them to record a lot of video walkthroughs of the code as documentation and keep them on maintaining the old project while you educate them on how to work in the new system. The video walkthroughs will be around forever and is a good training base for new senior devs you bring in.
Last, make sure you have good analytics (amplitude for example) so you know which features are actually used. Features that nobody uses can just be deleted.
Over time, you will have ported all the functionality that mattered to the new project and feature development in the new project will go much faster (balancing out the time lost refactoring).
A business making 20 million/year should be able to afford a proper dev-team though, what are they doing with all that money?
You should be able to get budget for a team of 5 seniors and leave the juniors on maintenance of the old system.
When it happens to post series-A companies it's usually just a team that leaves such as what happened when Bumble recruited the entire Barcelona-based engineering office of another company.