The Art of Thinking Long-Term Even When Money Is Running Out(medium.dave-bailey.com)
medium.dave-bailey.com
The Art of Thinking Long-Term Even When Money Is Running Out
https://medium.dave-bailey.com/why-visionary-founders-need-to-think-long-term-7ec4a5aae21a
42 comments
>> I like to do minor refactoring as part of any given new feature (even if unrelated). It helps take bites out of the larger pieces over time.
This hits the mark.
I don't think developers should even necessarily explain that this is what they are doing, because then they have to ask permission to do it.
I'm constantly thanking "myself from the past" when I go to implement some new feature and find that the surrounding code is clean and well organised and ready for that new feature to be easily implemented.
This hits the mark.
I don't think developers should even necessarily explain that this is what they are doing, because then they have to ask permission to do it.
I'm constantly thanking "myself from the past" when I go to implement some new feature and find that the surrounding code is clean and well organised and ready for that new feature to be easily implemented.
> I don't think developers should even necessarily explain that this is what they are doing, because then they have to ask permission to do it.
In my experience, it pays to be open with product managers and QA about what you are working on, how you are implementing it, what the risks and benefits are, etc. For example, it helps QA to focus their testing efforts on the areas that are most likely to be broken by a refactor. And having some understanding of how an app is built and where the problem points in the code lie helps product managers to develop a sense of how much effort a certain change might take, and reduces the chance that they will be surprised by some behavior in the app as the result of a change.
And if someone on the team wants to question me about the cost/benefits of a certain refactor and discuss alternatives, I think that is totally fair game. Same way that if I want to ask a question about the cost/benefits of a new feature and discuss alternatives, I feel empowered to do so. It's not about asking permission so much as it is about developing a shared understanding of the costs and benefits of the decisions that we make, and working together to optimize them.
In my experience, it pays to be open with product managers and QA about what you are working on, how you are implementing it, what the risks and benefits are, etc. For example, it helps QA to focus their testing efforts on the areas that are most likely to be broken by a refactor. And having some understanding of how an app is built and where the problem points in the code lie helps product managers to develop a sense of how much effort a certain change might take, and reduces the chance that they will be surprised by some behavior in the app as the result of a change.
And if someone on the team wants to question me about the cost/benefits of a certain refactor and discuss alternatives, I think that is totally fair game. Same way that if I want to ask a question about the cost/benefits of a new feature and discuss alternatives, I feel empowered to do so. It's not about asking permission so much as it is about developing a shared understanding of the costs and benefits of the decisions that we make, and working together to optimize them.
You make good points and I tend to agree with you.
On the other hand I remember on some projects there being real (HUGE) pushback from the client about doing anything that wasn't implementing features exactly as they define and "are paying for".
As soon as you declare that you are doing something "optional", it gets political, people start talking about it, it escalates to project manager, their bosses boss etc and the shitfight starts. Ugh.
On the other hand I remember on some projects there being real (HUGE) pushback from the client about doing anything that wasn't implementing features exactly as they define and "are paying for".
As soon as you declare that you are doing something "optional", it gets political, people start talking about it, it escalates to project manager, their bosses boss etc and the shitfight starts. Ugh.
Yup I guess what I was describing was more of an ideal software development environment, but fully recognize that there are many cases where being too transparent can cause issues. Hopefully those projects paid well, at least, to make up for all the frustration. :)
The best general strategy may be simply "tit for tat". Try going the high road first; if you see positive reaction, keep at it; if you see dysfunctional reaction (like parent here had), revert to doing it without asking for permission.
> implementing features exactly as they define and "are paying for".
The reason they're paying so much for it is that you didn't do the refactoring last time. Every time they refuse a refactor, all their future costs genuinely go up.
If they ask why the refactor is needed, why you didn't do it properly first time round: “You're constantly refining your business processes to satisfy ever-changing business needs; that's what I need to do to the code.”
The reason they're paying so much for it is that you didn't do the refactoring last time. Every time they refuse a refactor, all their future costs genuinely go up.
If they ask why the refactor is needed, why you didn't do it properly first time round: “You're constantly refining your business processes to satisfy ever-changing business needs; that's what I need to do to the code.”
> I'm constantly thanking "myself from the past" when I go to implement some new feature and find that the surrounding code is clean and well organised and ready for that new feature to be easily implemented.
The more experience you have with the reverse of that situation ("Dammit past koolba, what the hell were you thinking?!"), the more you value dedicating time to both doing things right and going back to progressively clean them up.
The real skill to learn is to properly isolate quick and dirty solutions so that they can be easily replaced down the road. The sausage factory does not need to be spotless on day one, just the entrance and exit doors.
The more experience you have with the reverse of that situation ("Dammit past koolba, what the hell were you thinking?!"), the more you value dedicating time to both doing things right and going back to progressively clean them up.
The real skill to learn is to properly isolate quick and dirty solutions so that they can be easily replaced down the road. The sausage factory does not need to be spotless on day one, just the entrance and exit doors.
There's a stigma that offering a candidate a 3-month temporary offer (or any such short time length) will make them not want to accept. However, I've had success is using temporary employment as a great way to figure out if the candidates would work out or not.
Main issue is not for the company, but the candidate. If he is a senior developer currently working elsewhere and you are trying to convince him to join, a 3 month temporary offer is a hard sell.
A probation period of three months is pretty common here in the UK, even for senior people. I've got 20 years experience and just checked my current employment contract, and I had one. Nobody seems bothered by it. Remember that if the company wants you gone, you're gone regardless of any probation period. The probation period only determines how many steps they have to go through to do it and how much notice you are given.
Yeah, not a chance I'd leave my current job for that kind of instability.
Pretty sure no one would. You'll only manage to get unemployed people. Who will bail if they get a full time offer during that three months.
I would. Why? Because I'm confident that they won't want to get rid of me at the end of that 3 month period. Hiring is expensive, and unless I mess up badly, there's no incentive for them to fire me. If they wanted someone temporary, why would they not just advertise for a contractor?
I wonder how much you'd have to pay someone in severance to make it worth it. If there's typically a 20% yearly salary piece for a recruiter, paying 10% direct to the employee in severance if their 3 months doesn't work out might make it work for a subset of people.
Could ask for a three month leave from current job. To travel the world or what not.
Even in EU it's a tough sell. Your current employer has to agree to it. Why should they, since you're leaving? It only complicates counting employees.
Better to have an employee that knows the grass is not greener on the other side, thus he/she has been there. A good employer will let you take a leave, its even a right in some EU states.
Doesn't mean you can go and work for potentially a competitor
I don't know that a 3-month temporary offer is really necessary. In California at least, where employment is "at-will", you can fire an employee at any time for almost any reason. My expectation when accepting a job offer is that if I am not successful in my role, I will be fired. Most jobs I have worked even have an official "probation period" for new employees where you have a set of goals you need to accomplish in your first 3 months of work, followed by formal review process with your manager and HR.
It's rare to fire new employees in their first few months, but it does happen. Similarly I have seen people join a company, and leave after their first week because a better job offer came in. It sucks when it happens... but overall I'd say the system works pretty well.
It's rare to fire new employees in their first few months, but it does happen. Similarly I have seen people join a company, and leave after their first week because a better job offer came in. It sucks when it happens... but overall I'd say the system works pretty well.
> I don't know that a 3-month temporary offer is really necessary. In California at least, where employment is "at-will",
Yeah, in an at-will state you might as well consider the "trial" period to be in place no matter what. If things don't work out well they'll just toss your ass to the curb. Maybe if you're lucky like me your boss will have a soul and give you some amount of severance at least.
Yeah, in an at-will state you might as well consider the "trial" period to be in place no matter what. If things don't work out well they'll just toss your ass to the curb. Maybe if you're lucky like me your boss will have a soul and give you some amount of severance at least.
When I took my first job I just assumed that it was a sort of trial.
Two people were hired. Me and another dude.
The other dude was invited to look elsewhere (they let him stay and work while he looked for a job so that was very nice), and I got a series of raises after they clearly were comfortable with me. They then started looking for a replacement for the other dude.
Effectively I assumed (correctly) I was on a sort of "trial" anyway.
Two people were hired. Me and another dude.
The other dude was invited to look elsewhere (they let him stay and work while he looked for a job so that was very nice), and I got a series of raises after they clearly were comfortable with me. They then started looking for a replacement for the other dude.
Effectively I assumed (correctly) I was on a sort of "trial" anyway.
We overestimate what we can do in a month and under estimate what we can do in a year. Love that.
It's basically Amara's law in action: We tend to overestimate the effect of a technology in the short run and underestimate the effect in the long run.
Yes, very very nice summary.
I was under a lot of pressure to increase sales. To boost the next month’s sales, I pushed the button on a big marketing campaign in which we reached out to a hundred potential clients with a time-limited promotion. The results were disappointing. [..] I realised that sales are about relationships
3) Tolerating a bad employee versus firing and rehiring. There is always a short-term reason not to fire someone who’s underperforming
Soooo you encouraged the board to fire you and hire someone who understands sales already, yes? And/or you understand that underperforming can lead to learning which can improve performing which you tolerate in yourself, so you tolerate in your employees, yes?
3) Tolerating a bad employee versus firing and rehiring. There is always a short-term reason not to fire someone who’s underperforming
Soooo you encouraged the board to fire you and hire someone who understands sales already, yes? And/or you understand that underperforming can lead to learning which can improve performing which you tolerate in yourself, so you tolerate in your employees, yes?
Underperforming is not about making mistakes. It is consistently being unable to learn and adapt. It is being unable to mesh with the rest of the team. It is feeling like "I wish I had not hired this person".
Also I think that different organizations have different thresholds for how much they can tolerate with an underperforming employee. In larger organizations, I have seen situations where an employee was not a great fit for the role they were originally hired for, but over time were able to move into a different role where they were effective. E.g. someone who can't write code to save their life, but is actually quite effective as a middle manager.
But in a startup situation where every new hire is going to make a huge impact on the team, and "money is running out" (as the article is titled), you might necessarily need to be less forgiving.
But in a startup situation where every new hire is going to make a huge impact on the team, and "money is running out" (as the article is titled), you might necessarily need to be less forgiving.
I don't think that a bad employee is someone that lacks experience. The article is not so clear on that point but I don't think it is what the author meant... That said, in my opinion, a bad employee is someone that gains nothing from experience and that is not going forward, and this can easily be detected after some time.
Are you saying that this guy should fall on his sword because he messed up once (and learned from it)? Or that, having messed up once, he's obviously not qualified to make firing decisions? I'm failing to find a charitable interpretation here that makes any sense at all.
Bad employees fail often, never try anything outside their comfort zone, and don't learn from their mistakes or take responsibility for anything. He didn't give an in-depth version of what he considered a bad employee to be, but it's fairly obviously implied by "not pulling their weight" to the degree that they eventually demotivate the rest of the team.
Bad employees fail often, never try anything outside their comfort zone, and don't learn from their mistakes or take responsibility for anything. He didn't give an in-depth version of what he considered a bad employee to be, but it's fairly obviously implied by "not pulling their weight" to the degree that they eventually demotivate the rest of the team.
I wasn't being charitable; but I completely missed that he said "one of my earlier businesses" and read "one of my earlier experiences (in this business)".
FWIW the "marshmallow experiment" failed when it was reproduced with more participants from wider backgrounds. Probably not something you want to hook your ideas onto.
https://www.theatlantic.com/family/archive/2018/06/marshmall...
https://www.theatlantic.com/family/archive/2018/06/marshmall...
No, the way you state is is simply wrong.
The study you link to confirms the correlation between the ability to delay gratification in the marshallow test and later success in life. However, it also says that when taking other factors in to account, in particular the wealth of the parents, the marshallow test does not add a significant amount of information any more.
So all we know now is that we have a number of variables that correlate:
- succeeding at the marshmallow test
- having wealthy parents
- be successful in life
Which one of these causes what is open for interpretation. For example, growing up in a stable and reliable environment (which more affluent parents can easier provide) might help to develop long-term thinking, which helps both at the marshmallow test and generally in life.
In any case, the study confirmed that if you don't know anything else about a person, the marshmallow test provides significant information about the probable success later in the life of that person.
The study you link to confirms the correlation between the ability to delay gratification in the marshallow test and later success in life. However, it also says that when taking other factors in to account, in particular the wealth of the parents, the marshallow test does not add a significant amount of information any more.
So all we know now is that we have a number of variables that correlate:
- succeeding at the marshmallow test
- having wealthy parents
- be successful in life
Which one of these causes what is open for interpretation. For example, growing up in a stable and reliable environment (which more affluent parents can easier provide) might help to develop long-term thinking, which helps both at the marshmallow test and generally in life.
In any case, the study confirmed that if you don't know anything else about a person, the marshmallow test provides significant information about the probable success later in the life of that person.
TL;DR here's the most important paragraph:
>Ultimately, the new study finds limited support for the idea that being able to delay gratification leads to better outcomes. Instead, it suggests that the capacity to hold out for a second marshmallow is shaped in large part by a child’s social and economic background—and, in turn, that that background, not the ability to delay gratification, is what’s behind kids’ long-term success.
>Ultimately, the new study finds limited support for the idea that being able to delay gratification leads to better outcomes. Instead, it suggests that the capacity to hold out for a second marshmallow is shaped in large part by a child’s social and economic background—and, in turn, that that background, not the ability to delay gratification, is what’s behind kids’ long-term success.
How can we access this post without paying a Medium subscription?
Just open it up in an incognito window.
Paywall in front of such article looks especially funny.
down for me
I like to do minor refactoring as part of any given new feature (even if unrelated). It helps take bites out of the larger pieces over time.
"Tolerating a bad employee versus firing and rehiring"
Inversely this also gets into something I often see where companies sit and wait for the best possible candidate (everyone claims to hire the best...) and so rather than hire and try people out they take a long time and hire someone and hiring being a non exact science.... doesn't work out. Maybe people need to try folks out, even maybe the person who doesn't have every bit of alphabet soup on their resume?