All Episodes
Previous Next
April 27, 2006 - Freedomain Radio - Stefan Molyneux
33:12
212 Business Management Part 1: Value

Paying the cost to be the boss

| Copy link to current segment

Time Text
Good morning, everybody.
I hope you're doing well. It's Steph.
It is 11.30 on the 27th of April 2006.
I had a fabulously exciting appointment this morning.
Which was a gentleman coming to my house and meeting with Christina and I and telling us exactly how much it's going to cost for us to put geological formations into our backyard.
We have a very large property.
We were sort of lucky to get a hold of it.
We didn't have to pay any extra for it, but it's like 130 feet long and 70 feet in the back and 60 feet in the front, so it's a little bit pie-shaped, but it's...
It's quite the property, and the challenge with that, of course, is it seems like a good idea when you buy it, but then you actually have to landscape it and so on, and particularly because Christina's running her clinic out of our home, at least for the next probably 8 to 12 months, we need to have it look good.
And so having people come over and say, I could drop $100,000 in your garden like that, right?
I'm like, really? Can I trail behind you and pick it up?
So this is all very exciting for words.
And now I'm heading into work.
I'm moving offices for a variety of reasons, and then demos and stuff like that.
But hey, your level of interest in the minutiae of my day, probably not staggeringly high.
So I'm going to take a suggestion from the boards, which was validated by a couple of other people.
And I'm going to talk about a little bit to do with business management.
In other words, how to take credit for other people's successes and to blame them for your mistakes.
You know, all of the kind of stuff that we as working stiffs are all perfectly...
Now, why would you listen to me about management?
Good question. Oh, I know why.
Because I guess I've been a manager for a little over 10 years.
I founded a company with my brother in 1996 and grew it with him.
And we then sold it in 2001, which was great.
It ended up being a couple of million bucks a year and 30 employees and so on.
So it was a good-sized company.
And... I did all of this with no training in business or software.
I've just always enjoyed programming and I was like the core architect coder guy and a sales guy and a manager.
I did pretty much everything in the business except for the actual finances, which is something that I really can't stay awake for.
I guess I've had some well-rounded.
So I built a team from sort of nothing to so on.
And then at this company, I joined as 25 people who report to me and so on.
So I have some experience with management.
So I thought I would share a little bit about idealized management or what management is all about, in my humble opinion.
And of course, it does tie into a lot of the authoritarian structures that we have been talking about.
I guess for the last couple of months and it also has something a little bit to do with coaching and parenting and so on so I hope that this is of interest to you.
Now basically management is a service occupation especially I'm at the director level so just one shy of the board level and at the level that I work at management is a service occupation And the primary skills that you need are empathy, negotiation, of course, and financial knowledge, right?
The ability to communicate effectively, to help people see multiple sides of the coin, and so on.
It's an advocacy position.
I'm client-facing, which means that I deal a lot with client requests and requirements.
It is my job to translate those requests and requirements into business terms that the CXO level, like the CFO, Chief Financial Officer, Chief Operating Officer, and Chief Executive Officer, who were sort of the holy trinity of, I guess, business management, so that they understand why we will need to invest in certain things and what the payoff is going to be, the payback is going to be, and so on.
At the same time, I need to represent the interests of my employees to the executive team, and I also need to, with a fair amount of delicacy and tact, I need to present the business facts of the company to the employees.
So if the employees, for instance, have a perception that we're making money hand over fist and why aren't I getting a bigger raise, then I need to communicate to them and they need to trust me in that communication that here's how the raise formulation came about.
We're not doing as well as you think we are, but we're not doing badly, and so on, and help tie that back to their individual performance, because the money within a company ideally is a big cycle, right?
So people at the bottom, they work hard, and it flows through to profits at the top, which then flow back to the employees at the bottom, and so on.
I mean, that's how a company should really work.
And if that is not occurring, in other words, if a product is created that is decided upon by senior management and the programming team, I mean in this instance you can translate this to whatever you like, if the programming team themselves did a great job of creating a product that the senior managers asked them to create and then that product did not sell, which is something that I've been wrestling with for the past little while in my job, Then it's not the programmer's fault.
I mean, the programmers are the ones who create the product.
They don't determine which product gets created.
That wasn't my job at this point either.
I sort of came into this company and the product was built.
Well, it was on its way to being built as I came in and then I finished building it.
And it didn't sell particularly well and so I need to translate that to the programmers to understand that it's not their issue that it didn't sell and also translate that back to the senior managers that it's not the programmers issue that it didn't sell.
You need to be able to balance an enormous amount, if you want to be an effective manager in my view, For instance, I mean, I know there's a lot of techies out there, so we'll talk about the software industry.
That's been my pretty much sole focus as a professional.
But I'm sure it can translate to other areas as well.
So in the lying weasel phase of software sales, which I actually don't do anymore and haven't done for quite some time, I'll go out and be perfectly frank about the limitations.
And it's one of these things you think it's going to be the end of the world, but it's not.
Fortunately now, the business has matured to the point where in the past, whoever lied the most got the deal because...
You'd say, my software does 10 things.
The other guy would lie and say, the software does 20 things.
And you would end up losing to the guy who said, oh yeah, the software does 20 things.
So you're basically punished for telling the truth.
And then... The guy who promised 20 things would only be able to deliver 8, right?
Because they couldn't even deliver to 10 because they were so busy working on the 20, which they end up not being able to deliver.
And so what's happened now is the industry has become mature enough.
The sort of gold rush is over to some degree that people now don't value excessive promises and they're looking for verification at all times.
And I think that's much for the better.
I mean, eliminate the weasels is always a good thing to do in life, so...
So when you're selling, you have to obviously put your best foot forward without having to promise things that can't be delivered.
If you do promise things that are not present at the moment, you need to be honest with the clients and you also need to find ways of motivating the employees because the coders don't like it when you promise things that are not there and you don't schedule them or you can't schedule them without overtime.
And why am I just working harder so that you make a commission and the company makes money?
How does it benefit me? So you have to translate that.
You have to make that business case at the CXO level that if we give the programmers these incentives, we will make this much.
It will cost us lots of things that you need to balance.
But it really is a service role.
The idea that authority has anything to do with, I don't know, feeling like you're some important guy and so on is pretty much the worst approach that you can take and will absolutely ensure that you continually fail as a manager, which means probably in most companies you get promoted, but we'll talk about that another time.
But it's a service role.
So, for instance, I took on a project management role for a variety of reasons recently.
It was not a huge project, like three months or whatever.
And the programmers don't like dealing with the clients.
And it's the public sector clients, so feel free to write me with emails about the hypocrisy of my paycheck.
I have no problem with that. I'll be happy to answer those two.
But it was a public sector client, and we were doing some adaptations to software which they had bought, which we were then going to roll into our main product line We're good to go.
Then they send emails to everybody in the entire hierarchy of the government saying how bad you are at what you do, what a terrible offender are.
So it's emotionally a bit grueling to deal with these people.
And the way that I work it is that I say to these people, you're perfectly free to say this.
I think you're going out on a limb here because I don't think it's our issue.
I think it's your network issue.
And the one thing I will request, since you have now involved everyone in the discussion, is if it does turn out to be your issue, that you send around a retracting email.
Because, you know, we have our reputation to worry about, and if we're perpetually perceived as the, you know, idiot mouth-breathing vendor who's, you know, one step above from pond scum in terms of ethics and competence, then we're going to have an uphill battle every time we have a problem with what it is that we're deploying.
So that tends to make people a little bit more hesitant.
Now, of course, they can always say, no, I'm going to just send out the bad emails and not the good emails, in which case I'll say, well, since you've involved everyone in the discussion, the emails that are correcting the situation or the perception can either come from you, which I think would be preferable to you, or they can come from me, in which case I'm not going to be able to run it by you first, and I want to, you know, that kind of stuff.
So they generally will. And that tends to defuse things a little bit and this is not the stuff that the average coder wants to get involved in.
It can be a little volatile at times.
People can be pretty aggressive and not exactly abusive but it can sort of happen.
And so in running this project with the public sector clients, you have to document everything.
You have to weigh and balance, you know, if they want another feature, which you also want to share with other clients, how much are you going to charge them?
Are you going to charge them? Is it worth it?
Is it worth the goodwill that you'll get for not charging them?
There's lots and lots of complicated things.
And some of it can be spreadsheeted and some of it's just sort of gut instinct.
And I think that this stuff's all measurable, but it's only measurable in long-term effects.
I mean, it's very not measurable in short-term effects.
So I did give them some work, and they ended up buying a lot more software for us.
And I think that had something to do with it.
You can't prove it. You can't ask them.
But overall, it's a very sophisticated and complicated balance to maintain.
And it's not something that coders want to do.
And that's very important.
When you are a manager, you have to make sure that you are taking on the tasks that the coders or whoever you're managing either can't do or would rather pay a million dollars than do.
So you're taking away negative tasks for them.
So I will sometimes bring the coders into a status meeting when I know that it's going to be controversial, and I will let them see me Fencing off the client and doing this sort of verbal combat with the client So that they see the value that I'm bringing and they see the stuff that I'm shielding them from so that they then don't have any problem with me,
you know, I guess getting paid more or having some authority or determining their wages or doing performance reviews because they understand that I'm doing something that they really, really don't want to do and that is something that is of great value to them because otherwise they wouldn't get paid if we didn't have these projects.
I'm serving my employees.
I'm serving the coders because I'm providing to them a valuable service and they are paying me to do it.
This is sort of important. It's very important to understand your employees are your customers.
They are paying for your income, if you're a manager, based on the fact that I make X amount of dollars and that's reduced from the departmental pool as a whole, which means that individually they could each get a certain amount more money if I wasn't around.
So, as a manager, you are overhead on your employees, and you have to provide them value for that overhead.
So, it's important to take away the things that they don't want to do, and this doesn't just mean doing everything that's unpleasant, because you've got to enjoy your job too, but It's important not to say, I'm not going to deal with difficult clients, but I am going to do all of the fun architectural R&D that we need for the next Janifer product, and you guys continue working in doing your maintenance coding in VB6. I'm going to do all the fun stuff in thinclient.net 2.0, right?
Or I'm going to learn C-sharp and whatever, right?
You want to make sure that...
You give them fun tasks and make sure that they know that you're assigning them fun tasks and so on.
And also you want to make sure that the money that they're paying you through their reduced bonuses and their reduced income is worthwhile to them.
And this, of course, is part of the whole 360 review concept wherein your employees get a chance to figure out whether or not They are getting value from you.
So when you talk to employees during the 360 review process, you give them your feedback on them and then it's very important that either they give their feedback to you directly or You get somebody else to receive their feedback so that you can figure out whether they feel that you're a worthwhile manager.
Because the last thing that you want is to be the guy who's assigned to them, like they feel like sheep and somebody has to be in charge of them because they're incompetent or whatever.
Programmers are highly competent, not necessarily in life as a whole, but definitely the programmers that I have are very competent in their coding in particular.
And so the one thing that you are going to have to make sure is that you respect that competence and provide value to them where they don't want to provide value for themselves or can't.
Programmers don't like particularly a lot of emotional conflict and so on.
Now, the other thing that I try to communicate to the coders as I sort of go out and do sales, like I say, okay, look, I just closed in March $400,000 worth of business for our company.
And I tell them that so that they understand that the cost-benefit of having me around is worth it.
I mean, I sort of crow out and give them an update every day, but I'll sort of subtly drop it into the conversation.
So that they understand, I don't even know if they know what I make, but they understand that I make X and I've just brought in 400k.
I don't bring in 400k a month, otherwise I'd be one of the biggest software sales vendors in Canada, but I definitely cover many multiples of my cost.
But by having me around, not only do I shield them from internal politics, I also am their representative to senior management, so I translate their needs and requirements, and I always encourage them to tell me what it is that they want and what would make them happy, and I translate that into a business case for senior management.
So I guess, and so that's sort of one aspect.
And the other is that I talk to them in subtle manners about the business that I've closed, so that they look at me as overhead, as anybody who's paying for a service either directly or indirectly is going to do.
But they also recognize that I'm bringing in far more money than I'm taking out, which adds to their capacity for raises and bonuses and so on.
So you want to be of value of added significance and hopefully to some degree hard to replace or ideally irreplaceable value to your employees.
So if they, for instance, I went down to a client in the States and I did a presentation for two hours to about 25 people, pretty senior, about what our software does.
And I enjoy those kinds of things.
And I think for them it would be a living hell to get up and have to do that.
And I like doing it.
And of course that creates sales and I get feedback on the next version and so on.
And so it's very important to your employees to show them the value that you're bringing to their income and to their job satisfaction and so on.
So when I first joined this company about three years ago, I inherited a department that had been built by somebody else, and there were a couple of really dysfunctional people in it.
One guy was pretty aggressive, another guy was cold and hostile, and so on.
And there had actually been tears in the workplace.
And this is, you know, obviously enormously demotivating.
And you will not get the best out of your people if they're not happy.
I mean, you won't even get an average, you'll just get...
Junk right out of them because they're not happy and they're just coming to work.
And they may not look for work because they're so depressed, but they're not going to go that extra mile for you and they're not going to be spontaneously and generatively creative, which is what you really need from employees, right?
Anyone can type in code, but what you want is for people to be enthusiastic about solving problems.
And they do that because they have the space to do it.
It's a creative and enjoyable space.
And they also know that there's going to be some fairly direct cash consequences for them by being creative and so on.
And that kind of stuff is important.
So I had to start to work to get rid of these employees, and it was a complicated business, and it took a couple of months, and I had a number of confrontations that were difficult and unpleasant.
I don't look forward to those either.
I mean, there's very few people who enjoy that.
When I brought the really aggressive guy in to Give him his first letter of correction or disciplinary letter.
I mean, geez, my hands were shaking.
I was queasy. But, you know, you've just got to do this.
If you want to get paid semi-big bucks, I guess, then you have to do this kind of stuff that other people don't want to do.
It's sort of natural and part of the business.
You also have to tell them that there's stuff that you take that's invisible to them.
A lot of times I'm not in the office because I'm traveling or whatever.
And so, of course, for some people in their office, they say, oh, he's never around.
Ah, the guy's never around. Like that guy in WKRP, Gordon Jump's character.
Ah, the guy's never here.
He would actually say he was the boss and he would say that to people looking for the boss.
Ah, the guy's never around. And you don't want to be that guy.
That sort of pointy head guy is, you know, on the road all the time and seems to be having a great time.
So I tell them, yeah, you know, I had to get up at like 7 o'clock on Sunday morning to take a flight and it was exhausting.
And I sort of tell this in an entertaining way just so they understand that I'm doing a bunch of stuff that they don't want to do that is taking me out of my home life for a day or sometimes more.
And that it's, you know, not that much fun and so on.
So, just so they understand that you're bringing value on multiple levels and that way they recognize the value that you're bringing to them and therefore they're going to respect what it is that you say.
And it doesn't mean that they're going to do what you say because that's the last thing you want as well as a manager is people just sort of to do what you say.
I mean, that's no good at all. I mean, you might as well sort of step into their hands and move them for them, right?
Now, the other thing that is a challenge...
In management is that you have a long-term goal, and particularly with coders, right?
People say to me, well, how could you become such a, I think, good manager when you have no experience managing coders?
It's like, well, because I was the theater director, and coders are the actors of the business world, right?
They're individualistic, they're a little vain, they're not so great with social skills, a lot of them.
And they're very creative, or at least they can be, but they also have, to my humble experience, a streak of mild emotional pettiness to them.
And they have to be handled with kid gloves.
They're like stars, right? You have to coddle them a little bit, and you have to have all the brown M&Ms in the bowl, and you have to have the right period with lime in the cooler and things like that.
I mean, because they're very creative, they're a little touchy, they're a little hypersensitive at times, and they...
They can turn on you, and when they do turn on you, it's very hard to get them back, right?
So you have to make sure that you keep presenting value, that you give them the room to be creative while keeping everybody aligned in the same general goal.
And that can be tricky.
I mean, I think someone said managing software is like herding cats, and I think that's actually quite true.
Everyone wants to wander off doing their own thing, and programmers will also, not often, but sometimes, enough to be of caution, We'll say, yes, I'm working on this, but they're actually working on something else.
So the stuff that they actually want to work on, they're going to be drawn towards.
The stuff that's actually paying the bills that the clients want is sometimes not so exciting.
So they'll tell you they're working on stuff.
They'll pad their estimates so that they can work on...
On their own stuff.
I don't mean their own stuff like private stuff, but stuff that is longer term, sort of harder to...
It's lower priority, right?
But more fun for them, and you have to give them the opportunity to do that.
I mean, so I sort of let them do that, and then sort of say, okay, let's break this into two, right?
I mean, let's make your job more exciting.
Let's give you two... You've got a month to do this, and I think you can do it in two weeks.
But I think maybe you're mixing in some mild research at lunch on this other stuff, let's just say.
But let's make your job really exciting.
Let's throw you a real curveball and see how well you hit it.
You can take two weeks to work on what it is that you have to do.
And you can also take two weeks to work on what it is you want to do.
I'm totally fine with that. I want you to have fun.
I want you to explore. I want you to be creative.
And it can be the first two weeks or the last two weeks.
You just can't be late. Whatever you want to do is fine with me.
But also be aware that I know that you are capable of padding your estimates, right?
You also don't want to get in that situation when you're a manager in software and other fields as well of having fights about estimates.
Because, you know, every single client in the world wants a down to the dollar not to exceed cost estimate while telling you that I want an upgrade without giving you any details.
Clients want a lot of wiggle room because as soon as they actually have details, then they're responsible for them, they can be charged more for exceeding them, and their job then becomes at risk.
If they keep things vague, they can always bully you into giving stuff for free, and they look like a hero, and so on.
So I've sort of more recently, I guess over the last year or two, adopted building the user interface first, so that, and getting clients sign off on that, and so on, and showing them it running, and And getting that sign-off, so that at least if you have to change something, it's not going to be the UI level, or if the client does want something changed at the UI level, you can fund more.
And this is not my idea, so I can't remember who came up with this, but it's a good idea.
I'd certainly recommend you try it.
It's a little bit more documentation, and it can be a little bit arts backwards in terms of the coding, but it's really, really worth it.
And even if this has to be marked up, that's fine, but you have to get sign-off on the interface, because that way everything you build under it is going to sort of make sense.
So... You have to make sure that you don't get into this battle with coders where you, as the guy who wants to close the deal, wants to get the cost as low as possible without harming your commission.
I'm going to have two pennies, right? I'm partly on commission.
So you want to get the deal down to something that is going to make you money and is going to make the client sign that much the quicker.
But the problem is, of course, that the coders don't want to end up having ridiculous estimates that they have to work nights and weekends for a month to complete.
Unless, of course, you're going to pay them a massive bonus, in which case you might as well just stretch out the deliverable a little bit more.
So you definitely don't want to get into that.
So I try to make it more like fun, right?
Like instead of saying that estimate is too high, you'll need to lower it, which is, you know, just basically, you're not adding value, right?
You're not adding value if you say, I want this cost to be lower.
I mean, all you're doing is stating the obvious.
Yeah, it would be great if we could hand over everything for...
A little money because then we'd have, you know, scalable whatever, right?
But everything that takes time costs money, is not scalable, so it has to be built on an hourly basis and so on.
So it really doesn't add any value to say to a programmer who gives you an estimate, I need this estimate to be lower.
I mean, that's just silly, right?
It's like explaining profit to someone.
I mean, it didn't really add any value.
And so what you need to do is you need to...
And, of course, you have to have experience coding in this.
You can't be the pointy-head guy.
And since I'd coded for, like, eight years, I sort of know some degree about it.
So you need to sit down and say, well, if we tried this, if we thought about that, if we stripped this feature, I think we could compensate with that feature, add a little bit here, take away...
Is there any, like, let's be creative.
Let's just sort of wildly...
Just for funsies, you know, just be creative.
Let's see if we had to bring this down, how could we do it in a manner that was credible?
And that is something that's more enjoyable.
And if you can't bring it down, then that's what you present to the client.
And then what I found is to say, do you need any extra time?
Like, if this is a really on-the-wire kind of estimate, then I need to know that too, because I'd like to build a little padding in, just for myself, right?
And then the programmers know that you're on their side, and so on.
And also you have to recognize that the client is going to push back.
So you need to put a little bit in there maybe.
Most clients do, right?
Also what I found to be very helpful is to break things down into options, right?
So it's like if you buy a car, everything that's an option is a price, right?
The sunroof or whatever.
And so telling clients, you know, we need this amount of money just to reserve the time for the project.
But here are the options in terms of what it is that you get done.
And then they'll say yes or no to various options rather than negotiating about price as a whole.
And that's a lot easier, right?
Yes, I accept the price, and now it's just a matter of haggling about options.
That's one thing, as opposed to giving them a big lump sum, and then they, hey, I understand all of this, I'm sure.
But I think that just providing value in these kinds of areas is very, very, very important.
Now, the other thing to do is, I mean, performance reviews are a big topic, and we don't have to cover it today, but performance reviews need to be specific and measurable and also have an economic factor to them, right?
If someone is not getting along with others, then you can say, okay, here's the limit that I see, and you don't have to do this.
It's all just choices and consequences, as I keep saying.
If you are a really excellent programmer, then you have one of two choices, basically within the technical world.
You can become team lead guy or, you know, with past it becoming manager guy, or you can become guru guy, right?
You just learn everything about the new technologies and figure out how we can achieve things that haven't been done before and so on.
And so if I have a great programmer, I'll sort of say, well, you know, I... You can do whatever you want.
You can certainly stay in your current position from now until the end of time, but if you wanted more money and more responsibility and sort of growth in your career from that aspect, I mean, you don't have to do any of that, right?
If you're just someone who comes to work to make money, that's totally fine with me.
But if you did want to, then these are the sort of two paths that you go ahead.
You will make more money in the long run.
Like, in the short run, you'll make more money probably relative to the amount you have to work as guru guy, but in the long run, you'll make more money as a manager.
But you'll end up having to give up coding at some point and you'll end up doing most of your time sort of negotiating with people and working with people and finding win-win situations and so on.
And that may not be your sort of kettle of fish or cup of tea or whatever.
And, you know, you can do that. It depends.
I think that's going to be tough for you and I would recommend that you take some courses outside of your job if you want to.
Because, you know, I don't really get the feel that you really like working sort of one-on-one with lots of people and so on.
You can do it if you want and anyone can do anything.
But these are sort of the options and If you go this route, it's going to cost you this in terms of time and energy and money.
But, you know, the growth pattern could be like this in terms of salary and so on.
So that they can make a cost-benefit analysis on what it is that they're doing.
And that kind of stuff gives them options, choices, cost-benefits.
They can make real decisions.
And that way, when you critique them, you're not just saying, well, you don't get along well with people and you should be better at that or whatever, right?
I mean, they give them options, right?
Now, the other thing that you have to do as a manager, in my humble opinion, is you consistently have to promote the value of your employees to senior management.
Because when you're a couple of layers away from the actual coders or the employees that you're managing, then it's very easy for them to see those guys as interchangeable sort of cogs, right?
I mean, well, they're just typists, they're just coders, they're whatever, right?
We can get a coder for 50k, you know, so why are we paying this guy 80k, right?
And So the thing that I sort of talked about, and I just finished securing pretty massive bonuses for the coders, because I said, look, our software is now like a million lines of code, and we have X numbers of coders, and each one of them is a specialist in this particular area.
If we lose any of them, it's going to be...
We're going to have to hire a pretty senior person who's had experience unraveling other people's code.
And there is some spaghetti stuff left over.
The previous manager foolishly let some students do some core coding, which is obviously not a good idea.
We had co-op students.
And it's not that they can't do it.
They just don't know how to write and comment code that is easily maintainable by others.
It's not that the code was bad.
It's just there's a difference between code that's well-written and works well and is efficient in code that is well-written that is maintainable by others, right?
And so, you know, I sort of give the cost benefit of these coders.
I said, you know, well, we're not at the high end of the industry average.
And here's the challenge, right?
We have a million lines of code.
if we have to hire somebody, like if one of these guys quits, and I have to hire somebody to come in and replace them, then it's going to take even a seasoned coder between four to eight months to become productive.
And it probably will be closer to a year before they get the code base to the degree that they can be as effective as these guys are.
As you know, there's just so much that is inherent to that size of a code base that you just, you know, oh, if I change this, well, I have to go these three modules over and make sure that that works.
And that's just not something that you can document very easily.
It's something that you just have to grow into.
So when I translate that into cash terms, it's like, well, we're going to have to pay pretty much the same salary, but we're also going to have to spend another 40 to 80K waiting for that person to become more productive.
So, and that's going to lower the client satisfaction, which might cost this, that, and the other.
It's going to slow down our new product releases.
It's going to increase the cost of QA because they're just going to be making the kind of mistakes that naturally happen when you don't know a codebase.
And so my rough guess is that the cost of us losing a coder will be between 80 and 100k.
Just a fixed cost.
I mean, we don't even know about the soft costs of, well, we don't get new features and our competitors do, so does that cost us a sale?
That's hard to measure. And so when I talk about that with a number of coders, and not that they're all going to leave at once and so on, but then I can sort of put that in context relative to bonuses that I'm asking.
So again, I'm getting the money.
I'm making their case. I'm having the negotiation with the board.
And so that's very helpful.
they understand the value of that.
And conversely, when it comes to getting new technology, right, no coders want to sit there working in maintenance VB6 hell forever, so I say, well, you know, coders recognize that if they don't get the newest technologies, then they have trouble maintaining their job skills, they become that much, they start to panic, right, like, they become that much less employable, and the only employment that they can get is working in this old code, which is a decaying orbit, and so, if we don't give them new technology to work with, and so, if we don't give them new technology to work with, then they will, at some point, the best ones at least, will leave,
And so that's going to be a problem as well.
So not only are there significant cost savings to going to new technologies after the initial investment, but we get to maintain the programmers.
So humanizing programmers, making sure that the senior managers don't view coders as sort of cogs in a wheel, interchangeable whatevers, but actually people with goals and desires of their own, with cost-benefit analyses that they're constantly working with, Because for some reason, senior managers, they always seem to sort of, well, yes, I make lots of cost-benefit decisions, but the people, they may be brilliant at coding, but they just don't make those same, you know, you don't want them to see people like that, because that's not very productive, that's not very helpful.
So those are a couple of my ideas about coding and managing.
I shouldn't say coding. It's about management and being able to add value to your employees.
I hope that this is of use to you.
This afternoon I'll talk a little bit more about the challenges of starting a company and the processes that I went through because I know that we have some entrepreneurs out there who are interested in this kind of thing.
So I'll talk about my experience in that and hopefully that will be of help to you too.
And if this is of all help, I mean if this is a consulting hour in your business career that's worthwhile to you, please drop by to www.freedomainradio.com.
Click on the donate button and let me have a kidney.
▲
Export Selection