staging-devopsy.kinsta.cloud

Tag: onboarding

  • Unstructured Data Management: Avoiding Insider Knowledge Gaps

    Unstructured Data Management: Avoiding Insider Knowledge Gaps

    Most IT leaders know that managing an unstructured data environment can be quite an undertaking. Before beginning an unstructured data management project, there are a lot of factors to consider including the number of storage devices, the size of a particular dataset, the number of files in the dataset and, perhaps the most intimidating, the unique environment the unstructured data inhabits.

    One-size-fits-all solutions can often inadvertently sweep important characteristics of unstructured data environments under the rug. Granted, this short-term, simple solution is easier than putting in the work to customize the best-fit solution for each organization’s data set. However, anyone undertaking an unstructured data management project should be forewarned—this methodology can create a longer-term detrimental effect known as “insider knowledge.”

    Insider knowledge is what is left when a group of people spend time setting up data management systems within an organization and then move on from their roles without passing along critical information about the data management system to those who take over. It makes things incredibly difficult for those who inherit the agglomerated system and, chances are, the organizations who currently have this problem don’t yet realize they have it.

    The Beginning of the End: Creating Insider Knowledge

    Today’s storage administrators have a lot on their plate and are perpetually spread thin. Their daily responsibilities typically include:

    • Creating shares and exports
    • Designing a file system layout
    • Assigning devices for each app or dataset
    • Hunting down unused data
    • Organizing and pairing workflows to datasets

    Often, with their busy day-to-day environment, the IT team’s decisions and actions are being made with a siloed approach. And as the project progresses, a unique language known only to the IT professionals overseeing the project is created. They may create their own tags and place files by a certain organizational system. However, most of this is not written down, meaning it is left to be deciphered like a code without an answer key. This language is the “insider knowledge.”

    Insider Knowledge and the Great Resignation

    Why is this an issue? As long as someone knows what is going on in the overall picture of the data, it’s fine, right? Well …

    Solely depending on the team of IT professionals who created the workflow means that they must stick with the company forever for their systems to make sense. After all, once the people with that knowledge leave, it is largely lost forever to the company.

    It is not a bet worth taking that the employees of a company will merely stick around to see the data management project to completion. The threat that insider knowledge brings to organizations is that only the people with an idea of how the system works can properly onboard the next hire. This is a great position to be in for the IT professionals who know everything about the system as there is a sense of job security, but it’s not great for the organization.

    For organizations, 44% of employees in the workforce are active job seekers. The Great Resignation has showcased that job seekers have the upper hand in the market today, and that good talent can be bought and poached from companies without a moment’s notice. When—not if—an organization’s IT team members move on, it is imperative to have a well-documented, organized foundation for the unstructured data management system so that the next team is able to pick up where they left off.

    Otherwise, when team members leave, they will inevitably leave knowledge gaps and questions will arise such as:

    • Are you hosting 20 TB of dead application data on your NAS?
    • Is this 20 TB of data something the storage administrator was planning on deleting, or is it important?
    • Are you going to pay to keep that data on Tier 1 disks?
    • Do you have old employee files that were archived to other storage devices but were never deleted?

    The implications of insider knowledge are important to remember before beginning to tackle a data management project. It truly is as simple as future-casting and deciding not to give a few people control over an entire enterprise’s unstructured data stores.

    Leave it to the Technology: What to Ask When Finding a Solution

    To manage unstructured data, there are now many tools on the market built with insider knowledge (and the pre-existing codes within organizations) in mind. By automating the process as much as possible, organizations can avoid a headache when their IT team moves on. Some questions to ask to aid in finding the proper tool include:

    • Location of data: How many storage devices are there? How many data centers are there? And how many countries are the data centers spread across? Do any live in the cloud? 
    • Scanning capabilities: Do the aforementioned locations of the data affect the tool’s ability to scan it? What functions can be performed, from just scanning to analyzing with big data abilities?
    • Presentation: How do you receive the information from the tool? Is it digestible and usable? Will it easily highlight the forgotten data sets? 
    • Aftermath: When you have the information at your disposal and have the insider knowledge in front of you, how can it help you move forward to promote a healthier unstructured data environment? 
    • Time: How long will it take? How much data can the engine scan? And will this affect business-as-usual?

    These are inquiries IT leaders must find answers to before deciding on the best solution for their organization’s long-term success. Regardless of how understaffed and overworked IT teams may be, in today’s modern data center, the last thing that should be done is give a few IT professionals complete control over an enterprise’s unstructured data management system.

    Staff turnover is never fun. In IT, it can severely impact an entire organization if IT teams are forced to start from scratch on projects because no one is left to translate the system’s language that was built on insider’s knowledge. 

    With the amount of data created each day, the time to clean up and automate the process as much as possible is now, as the time to decide on a solution that works for today was yesterday. IT leaders who take time to evaluate the new technologies and comprehensive data management solutions available will be poised to spend their budgets wisely to reduce the risk of setbacks, delays, cost overruns and even IT team turnover.

  • New Survey Highlights Codebase Size Problems

    New Survey Highlights Codebase Size Problems

    Sourcegraph and Dimensional Research have released a survey of developers at large organizations, which shows a massive growth in codebase size, number of repositories in use and complexity concerns.

    “The Emergence of Big Code – A 2020 Survey of Software Professionals” is definitely intriguing reading, and a few of the results are eye-opening—such as the difference between what development managers think developers are using to search code and what developers say they are actually using. But most of it simply validates what we all knew: Codebases are growing at an alarming rate, through a variety of growth vectors—support for new platforms, use of open source and internal development. Adding environment to code à la GitOps, systems reliability engineering and/or environment automation is adding a layer of completely new source and a layer of complexity not normally in the developer’s realm of immediate concern.

    I’ve been working with Accelerated Strategies Group over the last few months, and we’re looking at tools in this market. The ability to quickly get up to speed on large codebases and the ability to find a specific area in a codebase that is massive and/or spans repositories is a very real need that is not currently well-served. This piques my interest in what Sourcegraph brings to the table, but at the moment we’re focused on the survey, so perhaps in a future blog we’ll talk about Sourcegraph.

    While there is a lot packed into the survey, I think my favorite part is crammed in with other “What would you find useful?” results (the slide is below). Fifty-eight percent of respondents—all of whom are developers—chose, “Finding code by querying semantic relationships, not just matching a string.” As developers, these respondents no doubt are aware of the complexities of this type of feature, particularly in environments with a variety of programming languages and scripts (be they bash, SQL, whatever) all working together. This is huge, and first iterations would be shallow, but is a worthy goal. I’m intrigued to see how well SourceGraph et al solve it.

    Source: The Emergence of Big Code – A 2020 Survey of Software Professionals

    It is also intriguing to see more than half of respondents want the ability to explore ” … both known and unknown code with code intelligence that provides contextual understanding.” That, too, is a tall order. Code analysis has gotten better over time, but contextual analysis of large codebases is notoriously difficult. I’ll be intrigued in the near future to play with this concept and tools that offer it to see how reliable they are and how much human guidance is accepted and/or required to make it a reality.

    Code change velocity reporting and contextual information about code are both available and pretty solid from the majority of full-stack DevOps vendors. Perhaps that is why that particular response only netted 45% and 43% of responses, respectively—the other 50+% are already using them.

    We’re in an interesting time when consolidation appears to be on the upswing and the needs of developers and DevOps teams working in large codebases are becoming more clear and more complex at the same time. Over the next few years the needs reported in this survey will likely be replaced by more specific needs as these are fulfilled and find general use. The question of databases and database integration in large codebase migrations, for example, has these needs, but has other needs closer to the problem domain. As these general issues are resolved, expect your vendors to turn to those more specific, but every bit as complex, problems.

    And just keep rocking it. Find out what the tools and companies already in use at your org have added, and if those capabilities fit with your needs or can enhance your Dev/DevOps exercises. Keep the lights on, keep customers happy and watch for tools to help you make it even better.

  • Onboarding Is Science, Not Art

    Onboarding Is Science, Not Art

    Make sure your new team members are getting a well-rounded onboarding

    In Fortnite: Save the World, there is a questline in which a character named The Cloaked Star answers, “Figure it out yourself,” to a variety of questions from a new hero who was a DBA before the end of the world came. It is hilarious because, at that point in the story, the new hero doesn’t have the information to do so.

    Most of us have onboarding of new DevOps employees so simplified it would make us from five years ago cry tears of joy. Give them a container or virtual that is already equipped the way they need and they are ready to be productive, right?

    Welllll … kind of. Let’s stay totally stoked by the idea that pre-made tooling that will run fine on whatever they’re running it on is a huge step, then acknowledge that in the age of DevOps, tribal knowledge is still very much a thing. There is this other repository we hit for X, an alternate API for Y, that system that does not work the way one expects, and so on.

    We need to apply the same science to knowledge transfer that we do to tooling. It is not all self-documenting, it is not all obvious, and that knowledge absolutely needs to be transferred to new employees.

    Some of us have this down pretty well. Far too many of us do not.

    Two solid ways to transfer knowledge are documentation that is both thorough and up to date, and a buddy system. Both have strengths and weaknesses, but both address the parts that are not automated. If you go with documentation, make certain someone is responsible for keeping it up to date in the fast-paced world we find ourselves in. If you adopt the buddy system, make certain your team knows what information is most important to impart. While each buddy will be asked questions, it is the things that might surprise new employees that buddies should be prepared to impart.

    You are building the future “legacy code.” How far in the future that is remains to be seen, but given our rate of change, probably sooner than you think. Even if you use the buddy system, there needs to be some level of documentation included. The number of projects that use something like “Joe’s database designed in his basement” because it had the best caching available but then employee turnover removed everyone with any knowledge of the weak spots in the chosen product, is stunning.

    So make sure your new team members are getting a well-rounded onboarding. Make certain they have the info they need to be productive and avoid pitfalls that your team has already identified. Make their transition easier, and they’ll be productive sooner. And hey, you might avoid that big bug caused by someone’s lack of information.

    Whatever you do, no matter their level, make sure they know the important bits. And keep kicking rear, now with new team members, equipped to help you along.

    And don’t be The Cloaked Star. Help a new employee out.

  • Don’t Make Me Code Podcast: Onboarding Developers

    Don’t Make Me Code Podcast: Onboarding Developers

    Thanks for listening to Don’t Make Me Code, a podcast that discusses developer experience design and the unique challenges of building developer-facing products. Don’t Make Me Code is hosted by Steve Boak, co-founder and CPO at Opsee, and David Dollar, co-founder and CEO at Convox.

    In this episode of Don’t Make Me Code, Steve and David talk about some of the challenges of onboarding developers, and ways to make that experience better.

    This podcast is brought to you by Heavybit, a program that helps developer-focused companies take their product to market.

    [soundcloud url=”https://api.soundcloud.com/tracks/245152401?secret_token=s-4SUlM” params=”auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false&visual=false” width=”100%” height=”166″ iframe=”true” /]

    Steve: So, today we’re talking about onboarding, and what a pain it is for developer tool companies. It’s weird to me that, in the consumer world, we’ve got products that we can happily onboard into in seconds, and in the dev tools world, we go in the range of minutes, you know, five or 10 minutes feels pretty good.

    David: Yeah, we’re dealing with like, complicated things that people are integrating into these other complicated things that they’ve built, and it’s often not quite as simple as ‘just type in your email address and click a button.’ You know, you have to add some pieces to your code, or add some dependencies, or start instrumenting things—there’s all this stuff you might have to do to get started.

    Steve: And those requirements feel just unreasonable at times, I mean I can’t stand going through it, having to write code to onboard into a product.

    I remember getting stopped using New Relic for the first time, and having to actually write code before I could start using the product, and it’s discouraging, but required. And it’s just this infinite frustration and we, in our product, we’re trying to eliminate that as much as we possibly can, but, it’s a unique frustration of our world.

    David: Definitely, I mean, we’re trying to deploy applications to the Internet and they can be, you know, the variation to those is so huge, and so we spend a lot of time focusing on making it work out of the box without you having to make a whole bunch of changes right out of the gate. I think that’s really important.

    Steve: See, you and I are both at early-stage companies, we’re dealing with our Beta customers now, and that’s a very high-touch scenario, we’re interacting with them very closely and one at a time. But, we often have to deal with things like personal email addresses, where they’re signing up for the product as a company, but using their personal email, so, I spend about 10 or 15 minutes just discovering who the person I’m dealing with even is.

    David: Yeah, I mean, we definitely see that a lot, and it’s actually not just personal email addresses, you know, they’re actually probably trying us out in the context of personal accounts to begin with, or personal, you know, maybe they’re coming to bring a personal project like their blog, or something like that, to begin with, and they want to like, ‘Yeah, is this thing going to work, before I actually start to try and introduce this at work?’

    Steve: Yeah, and you’re trying to demonstrate value in an environment that, one, is not the intended environment, and two, might have totally different requirements around it. And, you know, for us at Amazon for example, we’re dealing with people’s personal accounts that have things like EC2 Classic support, which has been deprecated, and their production environments at work are a lot less likely to have that, but it’s something that we, as the makers of the product, have to consider just because of how people might onboard into it.

    David: Yeah, definitely.

    Steve: And even if we’re lucky enough to get somebody’s work email address, we still have to go through the whole test flow, where they put us in their staging environment, and give us a try. And it’s a tough constraint to be in a place where you’re going to have measurably less value, but still have to prove that you can be valuable to the customer.

    David: Yeah, they want to see, is this tool going to work for me.

    No matter how good your documentation, no matter how good your examples, most people are going to want to actually put their hands on it, and see how it works, and see where it falls down. And any experimentation is sort of like the name of the game for our target customers.

    So I think providing some sort of backdraft for that, and making it really easy to play with your product is pretty important.

    Steve: Yeah, and really considering how you’re going to provide value in these circumstances where you might be restricted is super important. Although, I have to say, this morning, we had a guy sign up for the product, put us in an environment that had literally nothing in it. It was an AWS environment with 0 instances and 0 groups, and we’re a product that health checks other things in the environment, and there was nothing to health check. That was a tough sell.

    David: Now he knows that you’re not going to take down his Amazon account, I guess.

    Steve: Yeah, and that too, the security check, right, like, half of the battle is convincing people that, one, you’re not going to break, two, you’re not going to break their stuff.

    David: Yeah, I think, and that’s certainly another driver for why people try with their personal accounts first, right? It’s like, ‘I’m not going to install this tool into my production account at work that I don’t know anything about.’

    Steve: Yeah, it’s been really funny actually to watch this, ’cause we do a lot of onboards in person over video chat, or even just watching their laptop screens, and we’re dealing with incredibly smart people. They watch, and they can see what our onboarding process is doing to their environment, and they go and audit everything, they’re checking every change to preferences, and they know exactly what’s happening. And they check us on everything, which is, you know, worrying, but also kind of cool to see just how good they are at what they’re doing.

    David: We basically, we get the same thing, people trying to install us into their actual Amazon account, it’s a pretty tough sell, we’ve had a lot of luck getting early users to just either create a new Amazon account and install everything there. Or we actually, we will create a whole bunch of, we pre-create a whole bunch of Amazon accounts, and just hand them out to people to let them start trying stuff. Anything we can do to reduce the amount of stuff that they have to do to get in and get experimenting, I think is really valuable.

    Steve: Yeah, that’s a really good point. Something we’re not doing yet at my current company but we’ve done in the past is create these real demo environments, where, you know, without creds even, people can try the product out online and get a sense for what it will be like without signing up, which has been a really useful tool for me in the past.

    David: Yeah, it can be pretty tough to do that with developer tools, just because, you know, you are talking about complex integrations in a lot of cases, but yeah, I think hugely valuable, when you get that right. If I’m a couple clicks away from actually playing around with the product, and maybe even a couple more clicks from you know, taking what I’ve been playing with and going live with it, any friction you can reduce in that path is going to help.

    Steve: Yeah, that actually raises an interesting point about the transition over the last few years from how enterprise software companies used to sell to how they seem to be selling now, which is the transparency, that now, things like pricing, and a real sense of what the product does. It all sounds pretty basic, but, these were things that you wouldn’t expect to see, five, 10 years ago. That selling a B-to-B product—you would have a button to contact the salesperson, and you might not even know what the product did on the homepage.

    David: Yeah, that’s exactly right, I mean, you still see a lot of that today, and it’s incredibly frustrating as a buyer of software to run into one of those. We try and keep in that in mind a lot when, from the other end of that it’s knowing how much it’s going to cost to knowing exactly the value that it’s going to provide for you, and how it’s going to make your life better, is really important.

    Steve: Yeah, it seems so obvious just to design your marketing at least so that people know what the product does when they come to your website. I can’t imagine a consumer company dealing with some of these issues, like the problem of multiple environments, and that we get people signing up with personal accounts, or with staging environments that are not the intended use of the product at all, but in order to win these customers over, we have to show value in them.

    David: Yeah, it’s tough, I mean, those environments can basically be completely different too, right? Like, my personal IDS account maybe has nothing in common with what my company’s looks like, you know, it’s like almost as if somebody wants to test your iPhone app by installing it on their Android phone at home first. It can be wildly different.

    Steve: Yeah, we were actually talking the other day about having kind of a ‘clean up’ button, where because we know so many people are onboarding this way, putting us in a staging environment or something first, that, they’ll have to kind of decommission some things and remove some things that they created in that first environment before moving to the other one. And so we’re trying to make that process easier for them too, as part of our onboarding. Which just seems ludicrous, but, it’s funny to talk about.

    David: Yeah, it’s almost worth trying to, is there some way that you can, through permission sets or something, like actually introduce them slowly into the production environment in a trusted manner, as opposed to here making them go through this experimentation phase first.

    Maybe if it was very guided, it might be possible to pull that off. So, you mentioned dealing with customers sort of on a one-on-one basis, in kind of a very high-touch manner, and that’s something that we’ve had a lot of success with, and we actually think is really important, you know. We have a public slack channel, we invite people to come in, we talk with people all the time, they ask questions about the product, that ask, you know, if they’re having problems, or if they, you know, even questions about Amazon, sort of things that are not even directly related to us, and kind of get a conversation going about that stuff.

    It’s been hugely valuable to have that kind of real-time, you know, I can just ping somebody and kind of get to know our customers individually, and know what they’re building, kind of the problems that they’re having, and that’s been really helpful.

    Steve: Yeah and, not only that we get to interact with them in real time, but we have a way of reaching out to them, and that, one of the issues we have, I think, as an early-stage company is that people are trying the product, they’re not necessarily engaged with the product, and they may not tell us about that.

    And so, having every possible way to reach out to them, but also then making part of our onboarding process actively reaching out to them during this process, and making sure they’re getting value, and seeing if they’ve found bugs, and just doing everything that we can on our side to make sure that they’re happy and engaged.

    David: Yeah definitely, I think, I mean reaching out, kind of keeping the engagement level high, and reaching out constantly, like, you almost always have to solicit feedback. I mean, you’ll get some really awesome customers that will come and tell you everything that’s wrong with your product, and those are great, but, for most people, you have to actually solicit that feedback. A lot of the best learning we’ve done in our onboarding process, and finding where the friction is, is just talking to somebody and seeing the questions they ask, you know, sometimes they’ll be like, completely off base, or weren’t even in the ballpark of things you were expecting them to ask, you know, you’re expecting them to ask, ‘How does something work,’ and they’re asking, ‘What does this thing even do?’

    Steve: Yeah, I think you raised two really interesting points there: one is like, when I was new to this, both new to startups and new to designing technology products, I used to take offense from that feedback. ‘How dare you criticize my work.’ But, as you were saying,

    The most vocal customers are the best ones. The ones who are going to tell you about every single bug, I cherish that now. That’s what we look for in our Beta customers.

    David: Two reasons: one, it exposes all of the things that you hadn’t seen, and two, those customers are actually your biggest opportunity to make them successful. If they’re engaging with you enough to tell you what’s wrong, they want it to work badly enough that you can just help them a little bit and they’re going to be great.

    Steve: Yeah, totally, if nothing else, if they’re complaining it means they care enough to complain, and like we were talking about earlier, partly because our onboarding processes tend to ask a lot of our customers, and because that can take significant time, it’s really on us to engage with our customers and figure out how we can help through that and how we can make it easier for them, and so, because of the burden on them, it’s a big thing for us to both learn how we can make that better, and also help them help customers through it as best we can.

    David: One of the interesting things that we’ve been seeing is that we get not only really technical people coming through our onboarding process. We get some very technical developers that kind of understand the basics of what’s going on, and they have one set of questions.

    We get other people that are maybe a development manager, or, in a lot of cases, I had one ops guy and he’s now AWOL and I can’t get in touch with him, and I just need help, and they have a completely different set of things that they’re looking for when they come to talk to us. It’s been really enlightening to be able to talk to all of those groups, and kind of see what it is that they’re looking for, because it’s very different.

    Steve:  Yeah, we, in speaking to the different kinds of people using the product, there seems to be a transition happening in that way dev teams are set up. And so, we’re dealing sometimes with developers, sometimes with operations people, sometimes people who identify as DevOps, and it’s almost like we have to learn something about the organization first, how their team is set up, and how they deploy infrastructure to even get a basis for the level of conversation that we’re having. And the level of knowledge—yeah, like you were saying, it could be anyone from a manager, I even had a couple of product people contact me. And so yeah, just establishing how the team is set up has been really important to figuring out how to talk with our customers.

    David: Yeah, understanding who makes decisions about that kind of stuff, understanding how new technology is deployed at their company, you know, it’s different for everybody. Like, some people are very gung ho, they just take new stuff and go crazy with it all the time, and some companies are very conservative, and it’s a lot different to get sort of the new shiny things rolled out for them.

    Steve: I think the contrast of, and we were talking about this a bit earlier, broad vs. deep, and open source vs. SaaS, so I think, Convox’s case is really interesting because you’ve got both an open source product and a SaaS product. Can you talk a little bit about the contrast and the priorities of designing those two products?

    David: Sure, yeah, I mean, so, it starts right at the beginning. Like you mentioned, we have the open source, we have SaaS, our SaaS product is not open source, so, there’s just fundamentally different ways that we work on those projects even, you know, with the open source we work in the open. We do a lot of discussion with the community before we make changes, you know, pull requests, and trying to get a lot of people involved in the changes and make sure we’re taking all kinds of viewpoints into account that is going to be useful for a broad range of people.

    And then, with the SaaS layer we’re basically saying, ‘Okay, we know have this opinionated, this is how you should be using this, and this is we’re going to codify the happy path, the way that you, the easy, couple-of-clicks way into the product that uses all of this crazy technology that we’ve built.’

    Steve: Yeah, and the contrast there is really interesting because open source tools almost by definition have to appeal to a wide audience, you want as many people as possible adopting them and contributing to them. That’s I think a big part of how they develop traction is you get an engaged community of developers who want to help, and SaaS almost seems the opposite, that, a really common startup mantra is this: ‘Make a few customers love you as opposed to a lot of people like you,’ and so, making a great, polished experience for a much smaller number of people seems really important to developing a SaaS business.

    At Opsee we’re dealing with this too, we’re only SaaS, we have no open source component, and so we really are trying to focus on a narrow set of use cases, and then make them as polished and perfect as possible, and we are competing with open source tools. So, sometimes we will see these responses like, ‘Oh, why would I pay for your tool when I can get the open source for free?’ But then there’s this back and forth about the development time required to customize it, and the different nature of those kinds of tools.

    David: And operating it, you know, it may be free, but somebody has to run it, somebody has to write a page up for it, and it’s easy to lose sight of that stuff.

    If you’re interested in being a guest on the show, or if you have a DX topic you’d like us to dive into you can reach us at dmmc@heavybit.com or @dontmakemecode.