Tag: sales

  • Product Evaluation Discussions

    Product Evaluation Discussions

    Instead of doing a predictions blog like 99% of the punditry, I figured I would do an awareness blog to wrap up 2022. Every year, you deal with a wide variety of people trying to tell you about products that may (or may not) be useful to your IT efforts. Some of the products even make it to the evaluation phase and while a few get installed, a smaller number get used.

    One of the many ways to minimize your time investment when talking about the bewildering array of new DevOps technologies and products is to know where the information you are consuming comes from. Here is my start at a list of information sources, where the information they impart comes from and how to get the most out of these sources.

    Marketing: The marketing team at any organization exists to spread the word about the product’s good points. Most marketing professionals only admit weakness in the underlying product if pressed. This is expected–if the sole purpose of your job is to tell the world why the product is needed, blathering on and on about the weak bits is not going to work out. But we all know there are no perfect products, even before you account for all of the environmental differences we’re installing into. So listen – they will present the product in the best light possible and have useful knowledge, particularly early in the evaluation process.

    Sales: The sales team wants to sell products, but they also are invested in happy customers. A good sales rep in high-tech is building relationships because organizations can create an income stream if the product’s value is realized on their site. This makes them practical. Their goal is definitely to represent the product and company positively, but in a light that admits more weaknesses and offers workarounds for the deal breakers.

    Sales Engineers: A lot of the sales team’s practicality comes from the team’s engineer(s). They’re the ones that have to help you get things installed and running, so they have a vested interest in the organization knowing ahead of time what will require work and what the risks are. Given a choice, talk to the SE alone before signing a contract–not because sales lies, but because the SE is there specifically to note issues that might crop up and how to get around them.

    Crowd Evaluations: Two things to remember about crowd rating sites–the participants are volunteers on the best sites, paid contributors on others. For paid contributors, well, the motivation is pretty clear. For many voluntary participants, the motivation is that they either love or loathe the product. Most of these sites allow vendors to respond to commentary, and some even allow vendors to have evals removed. No one offers a service where glowing vendor reviews can be corrected … keep that in mind. These sites are useful, and a few of them are mostly people that want to help. So find the good ones (I’m not advertising anything here, so no links–sorry) and use them.

    Analysts: Nearly all of the analysts I know–be they GigaOm analysts or a competitor–have experience in the field. They have done it, and most of them continue to keep their hands in the mix somehow. While I have not written (or maintained) a line of code in months, I do attempt to do so regularly. At the individual analyst level, the thing to watch is how long it’s been and how current they are. Some do pure analysis and haven’t touched the toys in a decade or more, and for C-level analysis, this is great … but for implementation recommendations, best to find a different source.

    Analyst Firms: This is where the real issues in analysis creep in. As an enterprise architect, I dealt with an analyst firm that–at the time, at least–would say whatever we wanted them to say. Totally useless in evaluations, but it worked well when convincing our technical advisory committee to approve the right approach. Each firm comes at the problems with its own lens, and being aware of a given firm’s slant is a good step to understanding how to use them–or if you should rely on them at all.

    Press: The age of pure-play press is largely dead, leaving a lot of “Paid for publication” out there. While there is still non-sponsored content being developed (one of the few rules Techstrong Group has for my writing of this blog is that I should avoid mentioning products; for example, making sponsorship they may pursue more about their vendor relationships and how many of you are reading my drivel), the majority of what is published as “articles” is “marketing” and should be treated as such. Reading this content can be useful for early education but not so much for evaluations.

    Internal Champions: Not the mandatory sponsor most projects require, but the person inside that is driving the org to look at a solution. These people are generally key. They know the environment, they know the product, they have ideas on how the product could help the environment, and they have a history in the organization. Whether their ideas about how various products help the company have panned out with other tools, for example. Of course the usual caveats apply… Security people still think you should be doing more to lock out bad actors – that is what they’re paid for, but that influences their evaluation of a new security product and how it fits in the org. Awareness of that type of vested interest can help filter internal champion input.

    There are others, or course, but I’m keeping this blog-length, and most–like MSPs or hosting providers–can be viewed as an extension of one of these (MSPs and hosting providers generally act like extensions of their chosen product’s sales and marketing, for example).

    And keep rocking it. All these people can help you understand how to make the environment better or your role easier. They can’t do it for you; that is your skill. Listen to what they all say and then act in the organization’s best interests. When I’m not a pundit, I tend to use marketing/crowd rating to get a feel for the space, then analysts and SEs to tell me about the space and specific products in it respectively. But figure out what works for your org and be aware of what viewpoints the various actors bring to your learning.

  • Dear Vendor: Letter to Technology Vendors

    Dear Vendor: Letter to Technology Vendors

    While I was writing my “Dear Management …” post, something was going on behind the scenes that inspired me to write another. We all have things we wish to say to vendors; this open letter picks some of the big points that they seem to invariably struggle with.

    Dear Vendor,

    We want to use your products, otherwise we wouldn’t even be writing to you. But depending upon who you are, and what year it is, you are struggling to meet our needs.

    We understand that your insistence that your new product or acquisition will solve all of the problems we don’t have is probably executive-driven, but give us the benefit of the doubt. We know our environment, and just because we use you for one thing does not automatically imply we want you to constantly push this other thing at us. By all means, tell us about your entire product line, but then back off. We will let you know if anything appears to fulfill a need.

    While we’re chatting, can we discuss pricing? Not just cost, but the byzantine structures you create, time after time? If you are going to use 15 different charges and fees to jack up the price there, we’re paying the bill – we’ll see it. You’re far better served by being forthright. Do you have any idea how many stories like, “I am not funding your Ferrari with your commission,” stories (this was actually said; it was hilarious – we went with a competitor) are out there? And they keep occurring. Just this week, the phrase “Your pricing is bonkers!” was submitted to a company. We want a good product at a fair price, not a cheap price up front that will drain all of our budget over time.

    Speaking of good products, let’s talk about security. Security issues with your product are our issues more urgently than they are yours. Don’t mess around; when notified, quantify the threat and notify us immediately, with suggested remediations until you can get a patch ready. Holding off until you can patch puts us in the unenviable position of being vulnerable and, worse, not even knowing we’re vulnerable. Use good coding practices so we’re not all caught off guard, and waive those secure coding requirements for no one. Interns and C-level execs are not professional coders (interns aren’t yet, and C-levels no longer are), and any code by these two groups needs to be reviewed by someone that knows your systems before they are sent to us for deployment. Don’t force bad updates on us. Do your best not to give us bad updates at all.

    Finally, on the topic of forcing things on us – guess what? We have a need for a specific tool in a specific environment. Telling us that starting next month your services are all “moving to the cloud” does not suit all of our needs. We get it, you want that data. It’s all the rage right now. You should understand that, if you stop serving our needs in your quest for our data, we’ll go elsewhere, eventually, no matter how reluctantly. Cloud is a great platform, but most IT tools need the versatility to run where we need them, not just on one platform out of many.

    And, as a side note, your AIOps generally isn’t. We know it’s the buzzword du jour, but honestly, if it’s basically the same product with some logic or a dashboard strapped on, that’s not AIOps, it’s normal product improvement. When you have deep data collection and analysis that uses trained algorithms, then you can join the crowd screaming AIOps. Until then, hush. You sound silly, and it undermines the rest of your messaging.

    Just to reiterate: We have a need, show us how you fill it, and let us decide if that suits our requirements. Then tell us about your other offerings and back off. We’re smart enough to smell vaporware, stubborn enough to resist your desire to collect all of our data and wise enough to judge whether or not you and the product you’re pushing this week will be around in a year or two. You serve a purpose, and we’re grateful you are doing this stuff so we can focus on our business. But please, make life easier on us, not harder. And if one more of you sells a product we don’t need to the C-suite, we may explode. That Sword of Damocles that you raised over us will inevitably fall, and your company’s reputation will suffer for it. But we’ll pay the price for trying to implement something we didn’t need in the first place.

  • You Can’t Sell DevOps

    You Can’t Sell DevOps

    A few days ago, I made an introduction for colleague Jason Dixon (@obfuscurity) over email, and described Jason as “a leading supporter of the DevOps movement”. A mere 17 minutes later, Jason replies to me, “Are you trolling me?”.

    I was aghast. Granted, I haven’t known Jason terribly long (measured in months), but I’ve been well aware of his impact and contributions to the technical community (pulling together Monitorama , for starters). I couldn’t fathom the visceral reaction. But it did get me thinking… Why would someone so impactful want to distance themselves from the description?

    For Jason, and many like him, it’s a question of intentions. To explore that, we’ll have to go back to the beginning, and for me the beginning was 5:20pm PST on June 24, 2010, in the last session on the last day of Velocity CA… a “choose your own adventure” talk by Adam Jacob (@adamhjk ), answering the question “what is DevOps?”.

    I happened to have my flip cam handy…

    http://www.youtube.com/watch?v=Fx8OBeNmaWw

    “So here’s the thing: DevOps is a cultural and professional movement. Period. That’s it… There’s no technology, you can’t patent ‘devops’. Can you market a DevOps compliant toolset? You cannot.”Adam went on to describe the evolution of the system operation profession, and the challenges he personally found. Then came the org chart of a traditional silo approach to a technical organization hierarchy: software developers

    Adam proceeded to challenge this approach with an alternative. “So this is everybody in a big pile. What we are is peers, and friends, and mentors, and we are having fun!”. Hysterically live in one silo, reporting into a director who reports into a VP, network engineers live in a separate silo, reporting into a separate director, system administrators in a third silo, and security engineers in a fourth. Proverbial walls erected between technical contributors, isolated from one another through a formal hierarchy. Need to communicate across to a peer? Better go up the stack to go back down.

    Our hypothetical example continues of a conversation in the big pile: “Hey security dude, what’s that you’re doing?!?”, and he’s like “I’m breaking into the web site.” And you’re like “How’d you do that?!?”, and he shows you and the network engineer is like “I can stop you,” and you’re like “How?!?,” and he’s like “Firewall rules.” And you’re like “Whoa! Firewall rules?!?” and the security engineer is like “Why did you need to do that anyway, that’s a protected network”. And then everybody is having a good time. And the Directors. They’re just helping you out. They’re propping you up.” cory2

    While improvised, comical, and at best a generalization of an industry in a hypothetical example, one key point stuck in my mind from Adam’s talk: DevOps was about people, and how they were most effective and happiest working together. That was the point of the cultural and professional movement: to be more effective and happier as a team, embracing a “shared outcome.” Software developers, network engineers, system administrators, security engineers, directors, VPs, etc., we all succeed or fail together.

    That’s not something you can sell. (In this context, I’ve specifically referring to selling a tool or service.) Nor is it something you can pin down to one definition applicable everywhere. Nor is it something that you can transplant wholesale from one company to another and expect the same level of effectiveness and happiness. You can’t “bolt on” DevOps to your existing organization with only tools and services. You can’t buy a toolset and expect your challenges to be alleviated. You have to understand the role improved tooling has played for those that have found success in this field.

    Tools can certainly be enablers and facilitators, particularly when they free up person hours from manual tasks (assuming you can channel the new found time in an enabling direction), and particularly when they increase transparency as to where technical problems exist, helping to avoid the “It’s not my servers, it’s your code. It’s not my code, it’s your servers” blamefest. How we interact with them, and the patterns of behavior they impose on us as people, can lead to drastically different results from one organization to the next, even if those organizations have identical tools.

    When our tools look like the first silo org chart example above, with a different set of tools presenting different perspectives to different teams bound together by a shared outcome, the tools end up dictating and reinforcing the silo organization hierarchy for how people work together.  To break down the proverbial walls, our tools instead must help define how people should work together.

    Tools enabling configuration management, automation, improved monitoring, metrics collection, and source control won’t ensure success in isolation, because the DevOps movement isn’t ultimately about the tools. It’s about the people, and how they will work best together to succeed. The right tools can go a long way toward removing barriers, enabling the right conversations, and setting the stage for success.

    Part of the challenge is that the tools are one of the more tangible and visible aspects of how we work. In can be easy to take a stroll through a peer organization and take note of the different tools, and attribute their success accordingly. You might be sold on the idea that a tool they have has been the missing piece to your success all along. Fight this first impulse to the tangible and visible, and remember that it’s hard to see how folks really interact. It’s hard to see how well their people, processes and tools work together to produce results in sunny-day scenarios. It’s even harder to see when the sh*t hits the proverbial fan. That’s where the real test is though, and that’s where the real lessons are to be learned. 

    So let’s all be a little more focused on the lessons learned in ways to work together supported by tools than on the merits of one tool over another in isolation. No doubt, it’s a harder and deeper conversation to have, but the value is tremendously greater. If we keep it up, maybe we can make Jason proud to call himself a leading supporter of this professional and cultural movement.

    Or maybe I was trolling Jason Dixon all along.