It is really funny, I agree with this 100% but also think because of the new norm of instant gratification this person is totally wrong. I have customers that all the time state they want to move to an openstack platform but have no programmers or unwilling to hire programmers. So of course we go down that path, look at the capex and opex and their brains explode. Then we look at aws/azure/vCloud and regular internal cloud with its associated costs and they come back from their heart attacks.
If you are a services company, he is right, you should be focusing on outcomes. But, if you can't tell me in 2-3 sentences what problem you are solving and how it benefits the customer you are doing it wrong.
This is a world of businesses and businesses need to make money, usually. Everyone gets so caught up on the new hot thing or the new "revolution" or what the competition is doing without thinking of what problem they are trying to solve or what actual value they are providing. This article says they provide outcomes, sure I can provide outcomes by moving you to SAP, or VDI, or hyperconverged, but what problem is this solving?
Don't tell me it "cut costs", it rarely does and lots of people smarter than me have shown that cutting costs are not the top priority of most leadership.
Back to the point of the article. I have made a lot of money in consulting. I now sell consulting services. You know how I do it? "Yes Mr customer how are you? Cool great, I am fine thanks. So what problems does your organization have, what are your goals, and how can I help you?"
Boom. You are all welcome.
Don't talk about product or you will lose to me or someone better. Don't talk money or you lose. Don't talk fads or you lose. Talk about the business and how you will help it reach its goals, overcomes it's problems, and grow!
This! I previously worked for a small software company that frequently got itself lost in the upgrade treadmill (its going to take N man months to upgrade underlying technology X/Y/Z to the latest versions). Yet in the end, I kept asking, what does technology X/Y/Z provide to the product that benefits the customer. Those questions frequently didn't have satisfying answers.
So, your not the cool, forward looking engineer when you favor using a 5 year old toolchain to build your product. OTOH, your also the engineer that doesn't have to come in on weekends to debug the death march bug that ends up being a result of doing the upgrade.
Sometimes you have to upgrade because the old version goes EOL and you won't have support anymore. This is a problem even if you don't add features and it applies to open source too.
Example: as soon as Rails 5 gets released, Rails 3.2 won't get any secuurity fix anymore. If the customer accepts the risk of running a system that could be exploited by automated attacks, all fine. If it's not, time to upgrade at least to Rails 4.2. They could also decide to check if the new vulnerabilities apply to their old version and patch it themselves, but it's probably more expensive and error prone.
I worked for a CIO who liked to be no more than one major version behind on software. He explained that he had been burned too many times by upgrades that had to go through several versions. If you are going to have to do the work anyways, why not reap the benefits for a while as well.
Yes your right, but not all products (and the product I was initially referring to) have large web facing footprints for security issues. At the indicated company the web facing portion was tiny part of the code base. I did monitor a few key technologies, and back-port or upgrade those (php, apache, ssl, etc) as needed. OTOH, we let our version of gcc get really long at the tooth, as well as refuse to allow additional technology stacks in certain areas (hence no ruby, python, node.js, etc, all rejected because they fill a similar place as the PHP we were already maintaining).
Amusingly enough, we avoided heartbleed because our version of openssl was too old! That was fun to try explaining to people, yah we backported the _1_ thing we though might cause a security issue a year ago into our ancient version of openssl, and your not affected by heartbleed. Yes, I know all the version checking scripts say its too old, but try to run one of the legitimate exploits against it..
The second part of this, is that an amusing exercise next time you actually have a need to call "support" for something. Find your local full stack/kernel developer and tell them, hey can you find this critical bug before the support guys find it.. and see what happens.
Keeping your toolkits small and lean, with a small set of dependencies does wonders for maintainability.
Sure, this happens occasionally, but more often you get an engineer who would like to upgrade just because there is some new version available. Who cares about stability, at least the bugs are new... :( At least that's my experience.
My experience is that more often the engineer knows the good reasons to upgrade but doesn't know how to articulate them to you, especially when you are known to be hostile to the idea of upgrading things.
I've experienced both extremes and everything in between, and I don't know that there is any consistent good or bad actor in these situations. Everybody has their own goals and it's human nature to overvalue the things that you care about and undervalue the things that other people care about. Good organizations are set up such that everybody can be a little biased in their priorities but the organization as a whole ends up going down the right path even if no one person is 100% right about what should be done. The decision-making in bad organizations often follows from one type of person with one set of biases making all the decisions. I don't blame people for having biases, I only blame people for denying that they have them and not trying to understand other points of view.
However, I can say for sure that there is a widely held view among professionals of all backgrounds (business, technical, whatever) that if someone fundamentally doesn't know how to articulate their point to someone else with a different background or set of priorities, then that person hasn't thought enough about why they should do the thing that they're pushing to do, and that there's a high probability that they're just doing the "overvalue the things you care about/undervalue the things other people care about" cognitive bias that everybody tends to do naturally.
I don't know if that's a good rule of thumb or not. There's at least some truth to it. But whenever I'm in a situation where I feel like someone isn't going along with me because I don't know how to articulate my point to them, my first thought is that maybe I need to think about it some more. I don't jump to thinking it's their fault because they don't speak my language.
This is a great comment and I totally agree both that there is almost never an actual "bad actor" and that being able to articulate a persuasive argument is highly valued in decision making. Maybe it is even a decent rule of thumb for coming to decisions under the inevitably imperfect conditions of the real world, but I do think that there are people who are just legitimately poor at articulating things, not because they are wrong or haven't thought things through enough, but simply because they are bad explainers, and that those people tend to be unfortunately undervalued.
Actually, I am an engineer, and I myself try to keep up with new technologies. But that doesn't mean I will use them just because they are new - in my mind that is additional risk. I have used my share of technologies which were made obsolete anyway, and it's no fun converting your codebase. But I guess the cool junior engineer who went to another company and left her old company taking care of her project using not-new-anymore / obsolete technology, doesn't care much about that. But I guess if she can't articulate why her newest technology stack is better, we should just switch?</rant>
As technical lead on some projects whenever someone comes will cool idea X, my question usually boils down to what is the business value of that idea.
If it doesn't improve business in some specific way, it doesn't matter how cool it is, it will just produce costs (developer time * hourly rate) without any benefit to the bottom line.
It doesn't happen if the company is willing to pay what they deserve, instead of wanting to have them to work for the same low rates as the ones they are paying to some offshoring consulting partner the other side of the world.
Or if they provide a work environment that makes one feel like coming to the office.
Good developers care about many factors besides shiny toys.
Good developers will also prefer to be well paid and have a good environment while working with modern toys instead of MUMPS infested codebase.
(This is not an argument in favor of running after every new technology immediately, but you'll have trouble hiring and keeping good development on a JavaEE 2 environment with SVN build system based on 1990 code practices.)
To most developers, interesting problems and technologies are part of the compensation. To attract talent to work for unattractive technology you'll need very attractive salary and benefits. If a developer can't expect to gain transferrable skills from a job, that must be factored in. Jobs where you gain experience nobody else needs are the start of many year-end careers.
OTOH, sexy startups often get away with paying less but, in return, offer environments a DAX-level customer simply can't.
I was too flippant. It isn't about "shiny toys", it is about being respected enough within an organization to be trusted to self-determine technical direction. It is difficult to hire good developers if you have a reputation for thinking you know best when it comes to very technical decisions like when it does and doesn't make sense to upgrade individual software components. It is definitely a balance, but the grandparent comment struck me as sounding like it was on the too-paternalistic side.
So that developer just took $cost_of_moduleA_rewrite euros/dollar/yan/whatever out of project budget because the module was "ugly".
So what value does the money spent reflect on the productivity gains of the users, costs related to build software, maintenance costs and so on.
If in the long run it has helped to reduce costs that without the re-write it would be higher than $cost_of_moduleA_rewrite, then it has business value.
If the developer has spent $cost_of_moduleA_rewrite without any positive outcome on project costs, then it doesn't have any business value.
You must be a frontend or mobile developer. On the server side using five year old tech is the mark of a proactive and daring company. Our code depends on Python 2.7 (released in 2010) and we still have to compile our own CPython every time we deploy on servers managed by the client.
This is less and less true in the new and excited cloud/devops world, for better or worse. There are plenty of companies that even on the server side are chasing the latest release cycle.
I can see your viewpoint, but I have to say that trying to keep up with the tooling treadmill has many tradeoffs.
If there is a new framework or tool to know about every few months and you change job every three, you will be spending all your time re-learning some strange new wheel and taking energy away from truly excelling at your current tool set.
On top of that, if we chase the carrot of technology we will always be using tools that are less than a few years old. In otherwords, un-tested by time and immature code bases without useful ecosystems and best practices.
RiotJS for example, there is a way it's designed to be used, and it is idealogicaly sound. But also naive. That way will evolve a lot over time as even just a small project revealed a dozen or so pain points to solve, that haven't yet been addressed by the community.
But working on an older codebase, communities have usually solved a lot of those problems with process or ammendments, and there is a wealth of information available.
So use 6 month old tech because you need to keep up with the cool kids who are hiring for that new tech specifically? Hamstring your current company in order to stay on top of tech/framework trends?
There's a middle ground - don't upgrade systems for the sake of upgrading, but maybe if you're building something new or working on a sideproject, investigate newer technologies.
If you're going for a permanent job, sure, you're largely tied to what is advertised.
If you're going for consulting gigs, no problem: Focus on selling solutions rather than specifics. Then afterwards offer up a solution based on new tech, and offer up a better alternative and explain how it solves their problems better.
The older I get the more I feel like we're an accelerate version of the fashion industry.
At least in fashion you can make an excuse that the design is thirty years old and most people don't remember the last time we did this.
With software it's every six or seven. It's hard not to judge my peers for having such short memories.
We were in the midst of one of these upheavals when I first started, and so I learned programming in that environment. It also means I have one more cycle than most people near my age. Now it all looks the same to me, and I understand those people who wanted to be more conservative. In fact I probably owe some people an apology.
Same here with regards to consulting. Clients pay and pay well to be able to pick up the phone and say, "We are having trouble realizing our goals/expectations/efficiencies in area X. How can you solve that for us and make our lives easier?"
And, just like that, another contract is drawn up and another invoice is sent. They don't care about the underlying tech. They only care about results, and what the results cost them. One-time consulting fees nearly always win over the prospect of hiring staff to take on the task, especially given that my incentive as a consultant is to time-gate a project and get it out the door so I can take on another.
I've come from your perspective before to customers (talk about the pain points, focus upon problem-resolution fit not tech, etc.) and it's awful hard to tell customers that have 80% of costs being related to labor and have reasonably well-performing technology that when they're talking to you only because you're trying to cut costs directly in your SOW it can be frustrating when touching that 80% is completely off limits and a political landmine.
Almost all the big vendors and sales teams start with the approach of looking for problems and trying to re-message their products and services to appeal to the problems of their C-level customers, not the engineers (whom never make the vendor relationship decisions). Several years ago everyone was "cloud-washing" their products to tell CIOs "oh yes Mr. CTO, we're ready for your cloud initiative" by slapping on a web frontend to their managed services and boxed software when they didn't have anything before to maintain a relationship. Those are red herring projects though I've found - it's just another way to keep vendors on their toes.
Another problem is that accurate problem statements can be very hard to get to without escalating to higher level managers that it turns out are oftentimes swayed by existing vendor relationships to get something done more effectively. From here, I simply have to ask "are you happy with the results your vendors have promised compared to what you expected?" and everyone complains about cost but you need to get away from that conversation honestly if possible - because IT at a company will never, ever, ever cost too little since it's a cost center.
> Everyone gets so caught up on the new hot thing or the new "revolution" or what the competition is doing without thinking of what problem they are trying to solve or what actual value they are providing.
These are my exact thoughts about how we now have like two dozen explicitly Docker-releated startups. Because Docker. Docker docker docker docker docker.
This kind of thinking doesn't factor in how many Robots work in enterprise software. They come programmed. You want to alter programming, esp in enterprise software, you need to be very high up the food chain. Any other route you take will be met with glazed looks and 'ok great...um...shall we go get a sandwich now'.
"Don't talk about product or you will lose to me or someone better."
I was with you until that little gem. Products fill a known need, solving a problem shared by many organizations. They don't claim that they can help everyone with all problems... but they do solve a specific problem, and if you have that problem, products are good things.
You can flip the attitude the other way by saying that consultants who act like everything they do is better than everyone everyone else will lose when working in well-established problem areas because they re-invent wheels. Expensively.
The truth is that good business can be done from either a broad consulting perspective, looking for new ways to help a specific customer... or from a narrow product perspective, solving a specific need for many customers. One is not inherently better or worse than the other. Just different.
>>Products fill a known need, solving a problem shared by many organizations. They don't claim that they can help everyone with all problems... but they do solve a specific problem, and if you have that problem, products are good things.
The point is that customers care about solving problems. They don't care about whether they are buying Product A or Product B to solve that problem. That's why you need to keep the conversation focused on the customer, their problems and potential solutions, and not the product.
Not only should you not focus on product, but when clients bring up product you should of course listen carefully and respectfully, but you need to consider that they are even then expressing ideas about how to solve their problems. Those ideas may be well thought through, but very often they are not, and comes down to trying to explain what they need based on what they know.
If a client says "we need product X", sometimes they really need it, but often what they are trying to communicate is "we need the stuff product X's marketing material says it will solve", and even that may be imprecise
Someone coming in quoting on what they say rather than what they answer when you ask probing questions about their actual problems will often quote for the wrong thing. And more importantly: Quote for something that someone else will be explaining to them why is the wrong thing while quoting for something more appropriate. Doesn't help if you come in with the best price if someone else has made your solution irrelevant.
The other aspect is that people often value the solution to a problem far higher than they value a product.
I have built a tool that I'm starting to roll out a service around now. And the interesting thing is that when I've talked to people about it, it quickly became clear that if I showed them screenshots of my admin interface and explained the software, they started comparing it to $20/month services that in fact deliver far less value in terms of results, but they still found it hard to see it as something more expensive.
When I instead approach it entirely in the abstract, and show people analytics of the outcomes and never tell them I have a pretty web-based interface, and never suggest they'll get a login to anything, people consistently value the service 10x to 20x higher.
Now, this doesn't work for everything - the reason people value it so high in the latter case is that the analytics makes it clear it deliver results that would cost them in that region otherwise. But the moment I start to describe it as a product, people go blind to the outcomes and value it based on other criteria.
tptacek and patio11 have touched on this previously too when talking about how to get your rates up by focusing on value delivered, and avoiding billing in small increments (e.g. bill daily rather than hourly, or even bill by the week or by the project if you can). But beyond applying just to the price, the overall principle also greatly affect whether or not you'll get a deal at any price.
Someone may even suggest the exact same technical solution as you, cheaper, but still lose out if they focus on the product and you're selling problem solutions and visions of where it will get them next.
E.g. I had a client meeting yesterday to walk through a proposal I'd sent, and the entire meeting involved me telling them what problem each part would solve and what that'd enable next. They sat there grinning through most of it, and kept starting to discuss additional work they just thought of that this would enable them to do later, and cost came up just very briefly at the end. Never mind the initial contract - selling them on the idea and the problem solutions now rather than technical details of a specific product likely already did 90% of the job of selling in 3x+ more work down the line.
If you are a services company, he is right, you should be focusing on outcomes. But, if you can't tell me in 2-3 sentences what problem you are solving and how it benefits the customer you are doing it wrong.
This is a world of businesses and businesses need to make money, usually. Everyone gets so caught up on the new hot thing or the new "revolution" or what the competition is doing without thinking of what problem they are trying to solve or what actual value they are providing. This article says they provide outcomes, sure I can provide outcomes by moving you to SAP, or VDI, or hyperconverged, but what problem is this solving?
Don't tell me it "cut costs", it rarely does and lots of people smarter than me have shown that cutting costs are not the top priority of most leadership.
Back to the point of the article. I have made a lot of money in consulting. I now sell consulting services. You know how I do it? "Yes Mr customer how are you? Cool great, I am fine thanks. So what problems does your organization have, what are your goals, and how can I help you?"
Boom. You are all welcome.
Don't talk about product or you will lose to me or someone better. Don't talk money or you lose. Don't talk fads or you lose. Talk about the business and how you will help it reach its goals, overcomes it's problems, and grow!