Month: March 2022
MMS • James Stanier
Article originally posted on InfoQ. Visit InfoQ
Stanier: The one thing I want you to take away from this talk is a great model that you can use to improve your communication at work, especially if you’re in a hybrid or remote working environment. What we’re going to do is get stuck straight into some backstory, going back to 2020. We all know what happened in that year. We had the global pandemic, which was really difficult. Then we all had to take part in the biggest remote working experiment that the world has ever seen, and not many of us were prepared for it. We had to deal with bad working setup, no space in our homes, distractions of home and family life all at the same time. It came as a shock. What also was challenging is that for those of us who had very highly collaborative, impersonal synchronous interactions as part of our day to day, those disappeared completely. We were as technologists used to the tools that you use for distributed communication. We use GitHub, we use Slack, and so on. You can only imagine how hard it must have been for other industries who aren’t even used to using tools like that to do their job.
This is a screen grab of the first ever UK government meeting that happened remotely back in March in 2020. Thirty five people in a Zoom meeting is gnarly in the first place. You can only imagine how difficult it would be to take a chaired physical meeting taking place in a properly designed chamber, and then bringing it all online with people who aren’t used to using the technology as well. For even people who could use the technology like myself, we found ourselves not always making the right choice about how to get help when we needed it. Sometimes we find ourselves remotely talking into the complete void if we needed something because we were stuck. We found ourselves with so many tools and so many choices, but it was difficult to make the right decision. We had to deal with email, and chats, and video calls, code and pull requests, recorded video, and live video. What was it that we should be using and at what given time? Who was setting any norms and standards for us to communicate with each other so that it will be effective? No one really did.
We Need a Model
What we really need, as we’re still in this world today is a model. We need a model that’s really going to help us be effective in how we communicate with each other. It needs to be easy to understand, and easy to choose the right way to communicate. This basically is a talk about communication. It’s a talk about communication at a technology conference, which is strange. If you were to be really pessimistic, and I’m not saying you should be really pessimistic, you could even say like a talk about communication could be a bit boring. I’m going to try and convince you that it isn’t. I’m going to firstly start off by showing you that communication is a bedrock of absolutely everything that you do at work because it goes through everything. Good communication improves your programming, because your program becomes easier to understand. If you’re in management or leadership, good communication is key. For anybody building consensus around decisions, building rapport and trust with your teammates, is all to do with communication. Writing great designs, building great architecture, giving feedback, all of this is the bedrock of communication. To improve it is worth it. It’s a great skill that really multiplies through whatever you do.
Normalizing the Playing Field
Before we talk about this model that’s going to really supercharge your communication, we’re going to do one thing. We need to set the right conditions, in our workplaces, in our teams, and in our brains, in the mindset that we’re taking to this so that we normalize the playing field for everybody. We normalize the playing field by treating everyone as remote, even if they aren’t remote to us. Because whether we like it or not, the world is always going to be some kind of remote now. It seems like the workplace trend is that we’re always going to have a hybrid model, at least. If we think about it, we always had a hybrid model because we always worked with people in different offices. We work with partners and clients who weren’t in our building. There’s always been a hybrid nature, a digital communication nature to what we’ve done anyway. If we treat everybody as remote from now on, we’re going to normalize both the practicalities and also the cultural side of our communication. Because it means that if we treat everybody as remote, everyone communicates via channels that everyone else has access to. It means that everyone joins meetings with their own camera and with their own microphone so that the experience is normalized no matter where you are. It means that there’s no dependence on any physical artifacts in order to get our jobs done. It’s fine if you’ve got a diagram on the whiteboard, but not everyone is near that whiteboard, so we should use digital tools so we can treat everybody as remote. Culturally, it means that there should be no bias for where someone’s located having any effect on the work they do, or how they can progress in the company, because we treat everyone as remote. It’s the leveling factor.
Thinking of this principle, and going back to our cabinet meeting, they actually have done a pretty good job here, most people have their own camera and microphone. There’s one square up here that doesn’t, and that’s the cabinet room. I don’t know who’s in there, because their name isn’t on their grid square. I can’t see them well enough because of how many participants that are on this call. I can’t read their body language. I can’t read their faces. Really, that cabinet room is not adhering by the principal, and those four people should be on that call separately. Treating everyone as remote is super important.
Getting onto this communication model that I want you to take away. It’s one model, but there’s three aspects to it. Those aspects are synchronousness, permanence, and humanity. I’m going to take you through each of those in turn. What we’re going to start with is this concept of synchronousness. If you’re a programmer, you’ve probably encountered synchronous and asynchronous before, because synchronous execution of code happens one after the other, and asynchronous is something that returns after some amount of time, after some wait. The same is true for communication. What we’re going to do is categorize it in this way, is that synchronous communication exists or occurs at the same time, or location, or format. For example, if I’m having a face to face chat with you, we’re having it at the same time, we have to be having it at the same location because we have to stand next to each other to hear each other. The format is the same because we’re talking and listening. Asynchronous communication does not have to exist or occur at the same time, location, or format. An email could be replied to two days later with a video call. A written document could then generate some documentation further down the line in a completely asynchronous manner. It isn’t a binary choice. It’s actually a continuum between these two things. It’s a spectrum.
This is where we introduce our model. Our first type of model is going to be between synchronous and asynchronous communication. What we’re going to do is between these two points is plot the different types of communication that we might come across in our workplace. Starting off on the left-hand side, a video call or a face to face communication, yes, it’s synchronous. We know about that. We have to be there at the same time, same place, same format. Then moving along, we have things like chat, so Slack, Microsoft Teams, and so on. We know that even though it is fairly synchronous, there is an expectation that if we’re both online, and we’re chatting, that our messages will become pretty synchronously to each other, but there may be some delay. We can carry on moving and have things like recorded video. You might think, that’s a permanent artifact. Then let’s think about how these things are used at work. Often a recorded video in the workplace is used as a backup of a synchronous interaction. There’ll be a meeting, and maybe somebody can’t make it, so you create a video and someone will watch shortly after, and then they’ll get back involved with that communication.
Then we have email, which is starting to get a bit more permanent. Now the expectation of email is different, isn’t it? If I send you an email, and you don’t reply for a couple of days, I’m probably not going to be too upset about that. That’s the expectation of email. That’s just how it works. Then we have written documents. We could be collaborating together to design something, come up with an idea. We could have a spreadsheet where we’re computing some costs of something. That document, we can work fairly asynchronously, we don’t have to be doing things at the same time in a collaborative way. Then the most asynchronous is a wiki or a README, because if you think about the time between something being written and something being consumed, it could be a decade. If the project is still relevant, and it still builds this particular code base, then the documentation will still be fine in 10 years’ time. It’s very asynchronous.
Thinking about this model, we can come up with our first key point, which is that the format that you choose carries an expectation. Your choice of how to communicate, implicitly tells the person receiving it how they should get back in touch with you. My example of talking into the void in Slack could be a massive team channel. I could be just saying, can somebody or anybody help me? If I really needed help immediately, then I probably would have been better off finding somebody that I know was online, and just having a video call with him in order to get help at that very moment. As well as choosing the right part of the spectrum to use when you’re communicating, you can also combine different parts of the spectrum together to fix some bugs that usually happen.
Thinking about meetings, I’m sure you’ve all tried to prepare for a meeting before. You thought, we’re well ahead of time, I’m going to write up all my notes. Put them in a document. Send them around to everyone the day before, therefore, everyone can asynchronously read. Then we can meet together and talk about everything while being on the same page. Then the meeting happens, and no one has read the document. It’s a pretty common problem. What we can do is combine synchronous and asynchronous communication together. This is a really cool example called silent meetings. If you’ve got lots of people who need to discuss something by reading something beforehand, then why not dedicate a portion of the synchronous meeting to read an asynchronous document, because then you can all take 15 to 20 minutes. Get onto the same page. Then spend the rest of the time having a really fruitful discussion. There’s a link there, which goes into the silent meeting manifesto in more detail.
Thinking about our model, we have to think about groups and we have to think about decisions. Synchronous means strong consistency, because if we’re all meeting together at the same time, format, and location, then we are completely consistent in our viewpoint. We have synced together. Asynchronous is where we have to think about eventual consistency. This is like programming distributed systems, distributed storage. If we’re using asynchronous communication and broadcasting it out, we might not even guarantee that everyone is going to read it. We have to choose a medium where we’re ok with that being the case. If everyone has to know something, a synchronous communication is essential. If it’s ok, if everyone catches up with time or doesn’t need to know, asynchronous is completely cool. If we’re trying to move ideas forward, then we can expand even further here, because a closed group has high synchronousness and high speed. If you’re working on a project with a small team, you know that you have autonomy to move forward and make decisions and make really rapid progress. However, when you’re thinking about broadcasting to a large group, there is low synchronousness and low speed, because 750 people or 1000 people to have input into a decision can sometimes just take too long.
Just recapping our first aspects of our model, between synchronous and asynchronous communication, we can plot all of these different communications on this. Then we can use this model to think about what we need to pick to set the right expectations for what we need in terms of responses, in terms of speed of movement, and in terms of how many people need to hear or see the communication that we’re doing.
The next aspect that we’re going to be thinking about is permanence. Permanence is something that’s quite interesting when it comes to communication, because there’s never before been so many ways in which we can capture the work that we’re doing so that we can share it later. When we talk about permanence, we talk about two sides of a coin. We talk about permanent being the state or quality of remaining unchanged indefinitely. That can be, not just in terms of the documents sticking around forever, it also means, how relevant is that document? Is it always going to be relevant? How accurate is it? Is it always accurate? Is it always useful? We have to think about these things. Impermanent communication lasts for a limited period of time, and not only the artifact lasts for a limited period of time, the relevance, the accuracy, and the usefulness also decays.
The really interesting thing about thinking about synchronous and asynchronous, and also permanence and impermanence is that we can plot them on the same model. We go back to where we were, but we also add impermanence over synchronousness, and we add permanence over asynchronousness. Because asynchronous communication requires permanent means to deliver a message, and synchronous communication is an impermanent exchange in the moment. What does this mean? We can use this model to think about why we found it such a struggle to adapt to remote working, because we spent most of our time on the left-hand side of this model, when we were working together in person. Because by the nature of being near people, by it being fun to talk to people, and nice to bump into people, we would have impermanent synchronous communications. The problem is, is that they leave no trace. When we all shifted to remote, and we wanted to find out information, we couldn’t ask people in the same way that we could just know someone next to us, or there will be that thing on the wall that we drew a while ago that we could look up. We’d lost all of the artifacts that we typically had in order to organize ourselves together. We spent too much time pre-pandemic on this side of the scale, and we spent too little time pre-pandemic on this side. This is where we have to change and we have to think about how we make things better for people when we treat them when it was remote.
The key point here is to think of the future. Are you making the future better, as you’re going about your communication day to day? Are you leaving a breadcrumb trail for other people to find? One of the things that we’ve done at Shopify to make sure that our developer documents are absolutely world class is that they’re not an afterthought. We think of the future as a first class citizen. The developer documents this year have been a headline part of the roadmap, where everyone from the exec downwards knows that this is a critical project that we do. As a result, this means that you dedicate the resources towards it. As a result, you also make these developer documents that really are beautiful, really well written. They’re fantastic, both for internal and external parties working with our platform. Making documentation front and center is a way to make it get done.
Another thing that Shopify does, which is fantastic when it comes to permanence, is a system called Vault. All of our internal documentation from our processes, our projects, our archive of people, their jobs, what they do, is all contained within this internal system called Vault, which is searchable. Anybody regardless of where you are around the world working for us, has access to the Vault. The company is open and transparent. You can find out anything that you need to know about anything at your convenience. Everyone uses the Vault because it is embedded within the company culture. We know that the process of getting things done involves documentation along the way. It involves broadcasting and blogging your project updates. It involves up to date documentation for your team. As a result of that collective effort from everybody in a distributed manner around the world, creates this wonderful leveling centralized platform to see what’s going on.
Outside of Shopify, there’s also other great examples that you can use. There’s architecture decision records, which are a great tool. If you’ve ever worked with a code base and wondered, why is it this way? Why has this particular design been used? Why is this particular inheritance pattern in place, it doesn’t make any sense to me as an outsider? Having a folder inside your code base where you can have these architecture decision records, allow you to raise pull requests that check in milestones and say, we are going on this direction with our code for this reason. That means that in the future, people can look back through your decision records, and understand why the code base is the way it is. If you go to that URL up there, you’ll be able to see some great examples of these design records that you can take away and use yourself.
Something else that is a great permanent artifact that you should think about as part of your projects are design documents. I’m aware that agile as a concept says that you should just move in small chunks and iterate, but there is building for the long term as a very future focused, important thing that you should be doing. Design docs are a really great way to make sure that you embed some process in what you’re building, so that you can get the right amount of design, the right amount of critique improvement before you embark on big journeys with your code. This blog post has a great template that shows you all the questions, headings, and subheadings that you should think about. I really recommend embedding design documents before any non-trivial feature that you build in your code base. Because in the future, people can then find the design documents, and like the architecture decision records, understand why something is a certain way because of a snapshot in time. That’s impermanence to permanence. It plots the same way as synchronous to asynchronous. We had spent way too much time on the left-hand side of this diagram pre-pandemic, and we need to be pushing to the right as much as we can, in order to make things better for remote working, hybrid working around the world.
The last spectrum that we’re going to talk about is humanity. You might think, why is it being called humanity? That’s a little bit strange, isn’t it? It’s an homage to a game, which I think is fantastic, called Dark Souls. Dark Souls is you play this Undead Knight, who is in this strange purgatory world called Lordran. There are these bonfires where you save your progress. These warming fires are the only connection that you have back to humans and humanity and the outside world from your purgatory. The longer that you spend away from the bonfires, the longer that you get damaged by all the other enemies. You begin to become a hollow shell of your former self. Actually, in the game, they call it going hollow. This is the way we think of remote working because too much time away from humans, no connections to the outside world does make you a shade of your former self.
We can plot on exactly the same scale from synchronous to asynchronous, what it means to be human in the Dark Souls concept, and hollow. If we spend more time on the left-hand side, then we get more chances to interact in a real way with human beings, which is really beneficial for us and our souls. If we spend too much time on the asynchronous side in the world of documentation, and READMEs, then we’re not interacting with humans, and we can just find ourselves just feeling like we’re missing something. The question and the key point here is that in your communication from day to day, are you restoring your humanity or are you going hollow? There’s an interesting dilemma here, which is that, as an engineer myself, I’m thinking about trying to be the most efficient. I want to write things instead of say things. I want to broadcast, communicate my ideas, so I get more input. All of those asynchronous means of communication, fundamentally, don’t connect me to humans in the same way that a tight close group of synchronous interaction has. You have to keep riding this line between the two.
There are some ways that you can embed humanity into your remote communications. Firstly, make it a part of everyone’s day job that they are socializing as well. This can be really simple things from having Slack community channels, where people can share what they’ve been up to. They can post what they did over the weekend, talk about their pets, cooking. Unite people by the habits and the interests that they have outside of work, and just make it a normal part of work to be socializing, because that’s what we did in the office anyway. This is a picture that I took, which I shared in one of our social channels, about a great rainbow that I saw the other week. It was really nice.
Something that doesn’t involve time and money that we do with Shopify is something called bursts. We are a fully remote company now. We don’t have people in offices. That’s great for all the reasons that we know remote is great, and it really suits me. We have to try and get together when we can, if people want to, of course, and there is budget and company time for people to book trips together as teams, as divisions, as departments, as even just people who live in a similar location, we go and do something fun. We go on a field trip together, go on a hike, go and investigate a farm nearby. Go and do something cool. Don’t just get together to sit in an office and work, get together as humans and do something that really connects you. Because then it really restores that connection that you have with people so that when you come away, and you’re working remotely again, you just trust people more. You build more rapport, and you generally understand the human beings that you’re working with, rather than the video grids that you have on the screen.
What we have to do is shift to the left of that diagram on purpose. We have to sometimes fight on wanting to be efficient, and instead, have a messy chat with people instead. Because it just makes us feel better as human beings. There are so many ways that you can work together in a social way as well. One of the tools that we use is called Tuple. It’s a piece of software that is really great for doing pair programming. We encourage people all the time to pair. I know that sometimes it feels like it’s more efficient to do your work independently to just tackle your programming problems on your own. Actually, pairing together on a ticket is not only good for problem solving, as we already know, but it’s just really nice to connect to another human being to solve a problem together and to also have a chat at the same time, because this is what keeps us human amongst this whole process. It keeps us connected to the outside world and feeling warm about being in touch with humanity.
Those are the three spectrums that we’ve talked about. We’ve gone through what happened before and after 2020, and how we’ve had to adapt, and how it’s been really challenging. Then we’ve had some motivation about why communication is really important for you to have an impact at work, especially in a hybrid and remote environment. Then we looked at this spectrum where we plotted things along the same line the same way, and just saw the interplay between synchronous, asynchronous, impermanent, permanent, and also human and hollow. How we have to be really conscious in the choices that we make, in how we talk to each other, how we communicate, how we build consensus, because we’re always going up and down that model in many different ways. We have to be thinking about us and our audience and the effect that it has on us all the time.
Questions and Answers
Goldberg: How do you handle discovery of documentation, especially in this world of Google Docs, Confluence, GitHub READMEs, if you have multiple streams, just the freshness, accuracy, versioning, and discoverability. What do you do?
Stanier: I don’t think anything’s a solved problem. One of the things that I mentioned is this internal Vault system, and someone had a question about what’s the difference between it and Confluence. By having this Vault documentation, that’s the place where things are expected to be up to date. In terms of what you put in it, it’s up to the team. If a team prefers to have something in GitHub pages to do their documentation, they can link off to it. If they want to use Google Docs, they can link off. The central point of discoverability is always this Vault system that we have. You open it up, you do Ctrl+K. You search for whatever you want. It’s expected that if you’re looking after a team, or if you’re looking after some software or some architecture, there should be a page on it that people can find and then route off to where they need to find out the information.
Goldberg: It’s like a central index in that sense.
Stanier: Yes, pretty much. It’s nothing new in a sense. Back in the ’90s, we had company intranets and things like that. The concept is the same. That is the central place where we want permanent documentation to be.
Goldberg: I get that, especially if you have multiple streams, if you have at least one place where you agree that things should be authoritative, then that already provides.
Stanier: Absolutely. I think, for example, the way that we track projects is that there are custom built things that fit how we do stuff. It links to the question as to what was the difference between Vault and Confluence. The framework for doing projects at Shopify is that you go to the Vault part that says projects, and then a project is proposed. There’s a review process. Then when a project is happening, updates are blogged to that page in Vault. What’s nice is that every project has a Vault page, every project has a blog of updates and documents. It’s customized because we use it, the central core of how we do. There are some tweaks to how we do our work.
Goldberg: I think that that’s probably the strongest part of this is that if you all agree to use it, then it’s going to be good. If you don’t, then the tool has lost its power.
Shifting gears a little bit about the humanity aspects of things, you mentioned, bursts. Who organizes the different burst activities at Shopify?
Stanier: There are two categories, there’s ones that the “company” organizes. For example, there’s some really cool stuff that’s been arranged for what’s happening this week and next week in Canada for hundreds of people in different tracks. Those are organized centrally by the operations team. In terms of smaller get togethers, it’s the thing where the engineering manager can do it for their team or a director can do it for their division, or someone who’s part of a committee can do it on behalf of the committee. The one thing that’s a negative side to doing it yourself is that organizing trips for people is really time consuming and challenging. Literally, I was thinking about, where could our team meet up in early next year? Then started to dig into, it’s going to be a lot of work to think about where to go, and the accommodation, and that kind of thing. There is central operation support for this, but some of it’s currently still in the staff, and that can be challenging, and we don’t have a good answer for that right now. The centralized ones are all arranged for us, so that’s nice.
Goldberg: At least you don’t have to organize all of them yourself. I agree, it’s a big lift to get that stuff done, especially if you have other job requirements.
There’s a lot of questions about documentation. Obviously, it was the focal of the talk. Going back to this idea of a permanent spectrum, you charted permanence and impermanence in line with synchronous versus asynchronous. I had this thought as well that things like chat are synchronous, but they’re also permanent, in that you can search Slack. Sometimes that’s an expedient way to get the information you need. I actually recently heard that Datadog has a 30 or 60 day expiry policy on Slack, so people don’t do this, and instead write documentation. I’m curious what your take is on things like Slack for sources of truth.
Stanier: Our Slack does have a retention limit, which does mean that old stuff will disappear, so that does force you with a habit. I’ve seen the other side of the coin, actually, with my previous company, our Slack didn’t have a retention policy for most of the time that I was there. What that actually ended up doing was, people would then over-rely on Slack to find stuff. Is that, yes, that design document was posted five weeks ago by Alice. I will search for Alice, and then it contains a link. Then you can’t find anything. I think chat can be permanent, but I think the context of chat is always maybe a bit more informal. You’re not presenting information for discovery, really. You’re presenting information to communicate primarily. Whereas if you force people to use permanent documentation, the audience changes. I think the way that you write it changes and the discoverability, so it’s about more. If you’re a Slack ninja, and you can find everything, then good for you. Personally, I find it really hard to find things in the history of Slack. I find it hard to keep up with channels day to day, to be honest. Having it somewhere that’s permanent that I can find it, is just a way that habits happen, I think.
Goldberg: I think going all the way the opposite, you mentioned that this year, in particular, Shopify has really invested in your public documentation. I think importantly, you mentioned that you can use it internally as well. Can you say a little bit more about the value of public docs as internal docs as well, and how you make that investment and make it work?
Stanier: The things that come to mind as you’re asking that question, like public accountability for things is a really fantastic way of raising the bar for quality. This can come through anything like open source projects as part of your work, because you’re developing in the open, it forces you to think about communication to the outside world a lot more. Having public docs like that is great, because you know the bar has to be really high because it’s for the company. Third party developers who are also building their businesses off of a platform rely on them for their income as well. It sets the stage for doing things in a really good way. The dev docs themselves, I can only go into so much detail, but we have some core principles when it comes to developing things on our platform. Which is that any internal APIs that we are building should theoretically with the right authentication be potentially available to the public as well, and it’s just a matter of permissions.
Goldberg: Yes, I love that concept because it’s like, always externalize.
Stanier: Yes, exactly. Because it just forces you to build things the right way. Then when you’re building something, and you’re like, this is an internal API. I’m just going to do some weird authentication hack to get access to a thing. Then you’ve got something that can’t be turned public. We have those little boundaries with our system, we always develop as if it were external facing.
Goldberg: You espouse the virtues of pair programming. Taking the time to build your APIs as though eventually they would be externalized, writing your documentation as though eventually you will be using them internally. Also, taking the time to do pair programming, which at the outset I have my own opinions about this, but I know some people think is wasteful, or half the capacity? How do you maintain this culture of putting time aside to do things in a way that maybe feels a little slower at first, but hopefully pays off? Do you get pushback on that, or is this really baked into the culture?
Stanier: It is really baked into the culture. Giving people access to the Tuple tool, and doing a pair programming session is part of our onboarding as well. As you onboard as the new engineer into Shopify, as well as orienting yourself, going through the facilitated onboarding, there’s days set aside where you pair with somebody on a problem and fix some bugs. You spend some time thinking about some problems together. That’s right from the start, that pairing is seen as “normal,” a normal way for teams to be doing things rather than an exception. I think personally, I was fairly skeptical about so much pair programming myself coming in. As someone like, I’m a director level, but it’s still really nice from time to time to understand what people are doing. I can program, so being able to say, “That looks really interesting, how about we pair on it?” I get so much context, and so does anybody who is pair programming on something gets so much context. For example, if you’re a principal engineer, or very high up on the IC track, taking 30% of your time every week and dedicating it towards mentorship of others, where maybe you can just be available to pair program with someone, that’s just such an amazing, useful, helpful thing to be doing. I think the more positive experiences that people have with pairing, it just builds. It’s like a muscle, it gets strong. You’ll be like, why wouldn’t I pair program on this thing, because that’s just such an easy way of getting things done.
Goldberg: I love that, especially as a mentor, if you are putting aside 30% of your time for mentorship, you could be having just a conversation, or you could be pairing. I think there’s a lot more going on in a pairing session. As you mentioned, that slides more toward the humane side of things, and so on.
Do you have any tips on how to improve the social and humanity aspect of the team, particularly when they’re in different time zones when something synchronous can be harder to do?
Stanier: Yes, it’s the age old question. I think we’re trying our best to balance teams so that they at least have three to four hours overlap every day. It is very challenging if you have someone in California and then someone in Eastern Europe, because they just don’t have any overlap at all. Making sure that teams have overlap in the first place is necessary. Making sure that there is time in the week to socialize properly. One fun thing that Shopify did that was cool, was called Shopify party. You can Google it. We had one of our AR engineers build a 3D world where you can do your meetings, but you can be a 3D avatar in this cool little island, and there’s loads of mini-games. You can have a chat about your project, but you can also race cars at the same time. That sounds really silly, but it actually worked pretty well. Just having an hour, or an hour and a half at the end of the week, where there is the overlap, and you just hang out and just play some games in this thing, and you chat about work. Especially if you’re running a team, like making sure that, yes, there is cohesion that’s built through achieving things together, but there has to be cohesion by setting aside time to just hang out as well. Just making it inclusive and fun.
See more presentations with transcripts
MMS • Courtney Kissler
Article originally posted on InfoQ. Visit InfoQ
Kissler: My name is Courtney Kissler. I’m very excited to be here to talk about a topic that is near and dear to my heart, leading with speed. I’m going to share a little bit about the experiences that I’ve had at three large organizations, and talk a little bit about my personal journey as I’ve made the shift to focusing on leading with speed.
I’ve been in the technology industry a little over 25 years. I started in infrastructure and operations, and worked at a couple startups in the Seattle area, before I moved to Nordstrom. At Nordstrom, I started in security engineering and moved around in infrastructure and operations, wanting to continue to get closer to the customer. I moved into development roles. Eventually my final role there was leading our customer facing technology team, so digital apps, web, in-store technology, personalization, loyalty, essentially anything that touched the customer. Then after 14 years, I decided to take a role at Starbucks, leading retail technology. It was very exciting to get a global opportunity and to work on a basically POS at global scale. Anything that was inside the four walls of a Starbucks store, my team worked on, including integration with the mobile order and pay experience through the Starbucks app.
After that, I decided to move my family from Seattle to Portland, and I took a role at Nike, leading digital platform engineering. That entailed our consumer data platform, our content and digital asset management ecosystem, digital inventory and order management, our retail technology, our sneakers app. A handful of things that were part of our digital ecosystem. Then I moved into a role leading global supply chain and logistics, and also worked on the ERP implementation there. After that, decided to move my family back up to Seattle, and took a role as CTO at Zulily, which is where I’m at now. I started in January of this year. I’ve been going through the onboarding process, and really enjoying spending time with the team and getting to know the organization better. I’m super passionate about creating a dynamic learning organization and focusing on a generative culture. I believe people are the number one asset in any organization, and so I strive to focus on teams and people, and try to be a lifelong learner.
Every organization is different. Even though I’ve seen common patterns, or I’ve heard about common patterns, or anti-patterns from others that I know in the industry, you still need to understand the context in the organization that you’re in. I’m a big believer in the first 90 days framework. I use that whenever I take on a new role, to really spend time listening, learning, making sure I understand where the problems are before I introduce change.
I’m going to back up to 2012, this is what I would call my ‘aha’ moment. We decided as a company at Nordstrom, that we were going to go big with digital. At the time, we had a digital presence, but it was not where we were focused. We made the decision that that was going to be a huge growth channel for us and that we were going to go big, which led to a shift from optimizing for cost to optimizing for speed. I call this my ‘aha’ moment because my entire career until that point, IT was really treated as a cost center. You’re trying to drive as much efficiency out of technology. Most of my peers were in that same situation. It was, how do you drive cost and efficiency?
You may ask, why speed? One thing I learned early in my shift to optimizing for speed was there were a lot of myths or misunderstandings. What I love about this table that I have here is that there is a lot of industry data. This is from the book, Accelerate, and from the years of State of DevOps Report, and the research and data that demonstrates, when companies are focused on speed, and they’re doing speed right, they are not compromising quality. High performing technology organizations can get both, but in reality, when you’re doing speed right, you’re not compromising quality. Focusing on lead time, understanding how long it takes to make a change. Really focusing on your deployment frequency. Percent change failure rate, and that’s where if you’re focused on this balanced scorecard, then you’ll be able to see if you are not creating the right capabilities to be able to go fast, and also not compromise quality. I truly believe, and this is informed by my experience, that if you optimize for cost, you will not be able to deliver at the pace that you need. If you optimize for speed, you will still be able to gain efficiencies and cost savings.
Optimized For Cost
Just a little bit of the attributes of the organization when we were optimized for cost, so probably not surprising, annual planning. Most organizations have that. Actually, every organization I’ve been in does annual planning. We funded projects or programs, lots of buying, not much building. There were a lot of shared services. I think when cost is the focus, often there’s a lot of centralization and shared service organizations that help with optimizing for cost. Lots of waterfall delivery methodology and big batch releases. Here’s what I learned. Those structured methods were really good at managing budget, scope, and timeline. We also had a very high project success rate based on those criteria. When we really look closely at our delivery, we couldn’t ground it in customer value delivered. We had feature teams, production support teams, operations teams. The production support teams weren’t really set up for success. They couldn’t get feedback back into the dev backlogs. A lot of the work they were doing was just repetitive tasks that could be automated, but they didn’t always have the investment to do it. Outsourcing was actually a really good model when we were optimizing for cost, because we could get a lot of savings by taking certain work and leveraging an outsourced partner.
Nordstrom. In 2014, I gave a talk at the DevOps Enterprise Summit, where I go into a lot more detail on this example. I’m going to share a little bit about what was going on then. Our customer mobile team, we were not moving fast enough. We were releasing twice a year, which just was not frequent enough to keep up with what we needed to deliver for our customer. We had a senior leader move in to lead that team. We hadn’t brought that in-house, and we brought it in-house so that we could deliver our digital experience ourselves. That leader spent time being very curious, asking the team a lot of questions about what it took to deliver value to our customer. Essentially, he was documenting the value stream but he didn’t call it that. He basically just asked a lot of questions and then turned around and shared with the team and said, did I get this right? It looks like we spend time on this or we had a handoff here. He made sure that he really incorporated the reality into that value stream. He learned that our lead time was 22 to 28 weeks. With all that data and information, he was able to then problem-solve with the team, and over time, about two years later, we were doing on-demand releases. It became a business decision around when we would deliver our features into our mobile experiences.
Some of the things that were done during that time, we broke down silos. We had a lot of handoffs. We had a QA team. We had a production support team. We had a release management team. We said, we want those teams to really be shared ownership of outcomes in order to deliver value to our customer. We brought the teams together and really focused on improving our lead time. We also had this thing we called a hardening sprint, which was essentially a timeframe between when code was supposed to be complete, and before it was delivered to our customers. What it became was extra dev time. What we found was we were actually having a lot of quality issues, because that sprint was not really being used to harden the release. What we found was the hardening sprint was really a risk management theater. It wasn’t really achieving the outcome. Instead, we invested in, how do we build quality in early? How do we have ways to automate our testing? How do we understand the health of our features before we deploy them to production? Then we also created a single backlog, so instead of having features in one backlog, support and operations in another backlog, we said, work is work, we should be prioritizing all of this together. Resilience is a feature, so if we’re having performance issues in the app, or high crash rates, they really should be prioritized right alongside the next feature.
Then I’ll tell a Starbucks story. One of the things that I have on my first 90 days list anytime I take a new role, is to find out if the team has a value stream map. I ask that question, do we have a value stream map? I got back, yes, we do. I thought, that is wonderful. Awesome. What’s our lead time? The answer I got was we have a monthly release cycle. I’ll talk about why that was just a very interesting discovery to make, and then how we manage through it as a team. I gave a talk at the 2016 DevOps Enterprise Summit about the Starbucks journey. The main takeaway here is that lead time does not equal the release cadence or the release cycle. You would think, if I’m on a monthly release cycle, then maybe my lead time is 30 days. It turned out for us, our lead time was 84 days. That allowed us to then start to problem-solve, and say, how might we reduce that? What we decided to do is we took what we call the run ahead team, and we said, see how you can focus on the things that are contributing to the high lead time and see how fast you can deliver a feature into production. With high quality, and basically looking at it through that lens, they were able to deliver in 11 days.
That team basically broke down their features into smaller increments. They invested in the deployment pipeline, because there were some gaps in automation and ways for us to understand the health of the features. We also implemented a version of the Andon Cord. If you’re familiar with the Toyota Production System, the Andon Cord can be pulled by any employee, stop the line if they see a problem. We did the same for our deployments. We’d have a visual indicator. I actually had a screen out when we were in the office where you could see and it would go red, if someone either manually pulled the Andon Cord, or an automated testing cycle pulled the Andon Cord. We would swarm and we would get the problem resolved before we would go forward with the deployment. We also introduced the DORA metrics. We started tracking our deployment frequency, our percent change failure rate, our lead time for changes, and our meantime to restore service.
At Nike, I give a little bit more information about this in a 2018 talk that I gave at the DevOpsDays Portland. When I joined the organization, most teams were using the Scaled Agile Framework to deliver software. I got asked early on in my onboarding if I would sponsor certification for more individuals to learn SAFe. As a counterproposal, I said, what if we took a handful of teams, and we introduced value stream mapping? We landed on five teams. We did value stream mapping workshops. This is the result of our product detail pages team’s problem solving that they did after the value stream map. What they found was they had 33 steps in the process with 49 pain points. They were able to reduce from 33 steps to 22 steps. They took their delay time, which was the amount of time where basically, no processing is happening. Either you’re waiting on somebody, or there’s some delay in the value stream. They took that from 30 days to 19 days. This data was leveraged in a monthly review with our senior leadership team, and teams were encouraged to continuously improve and have the space to problem-solve against these pain points on a continuous basis.
Zulily: Optimized For Speed
Now I’m at Zulily. We are optimized for speed and learning. We have annual planning. Every organization I’ve been in has annual planning. We are focused on, how are we going to minimize burden in the teams? Burden exists everywhere. It is like, how do we continuously invest so that it’s easier to deliver value? We have a lot of dependencies, even though we are hyper-focused on speed and innovation, for most of our strategic initiatives, it takes multiple teams in order to deliver that value. How do we focus on making that as friction-free as possible? One thing that we have started to leverage is technical program management, as a discipline and capability so that we can have individuals who are constantly looking at, how do we make work easier? What are some of the technical investments that we could make to minimize or eliminate dependencies within the organization.
We also have a self-organized standards working team. Sometimes, standards can be seen as bureaucracy. Our team’s elevated that, they think we should have some amount of standards so that teams can actually move faster. We have a team that is focused on, what is the minimal amount of guardrails and standards that will enable speed? We’re working through that as an organization. We are also introducing the DORA metrics, so each team is starting to elevate those four metrics that I mentioned earlier.
Outcome Focused Teams
This is where I genuinely think this is a version of a North Star, trying to get to outcome focused teams. One thing that I believe is value stream mapping is such a great technique to get shared understanding and really understand the baseline for lead time. Then focusing on outcomes versus outputs. This example is from Nordstrom, where we focused on our feature count, like how many features are we delivering? Versus an outcome, which was, how do we become a 5-star app? It really shifted our mindset and thought process around what work we took on in order to achieve that outcome. Then to get to on-demand releases, technology cannot be the constraint for delivering value. We really needed to focus on, how do we become an enabler?
I also believe passionately that leaders need to evolve. I talked about creating a dynamic learning organization, generative culture. This table is the Westrum model. I believe passionately in striving for creating an environment that is demonstrating the behaviors that are listed under the generative column. How do you embrace when a team member or a team brings you a problem? How do you ask questions instead of blaming? My first question is never who. If something went wrong, I talk about how. Like, how did the system break down? What does the team need? What support can I provide as a leader to help?
I also believe senior leaders should be accountable for strategic enterprise prioritization. That might sound like it is taking away or not empowering teams. I truly believe that if strategic prioritization is done, then teams are empowered with context and accountability. Then they’re not needing to reconcile conflict that should be reconciled at the senior leadership level before it gets to the teams. This takes discipline. It takes a balanced point of view. Not everything that gets prioritized can be a big revenue driver. There’s compliance activities. There’s regulatory activities. There’s test and learn that if driving revenue is the hurdle that needs to be addressed in order to invest in something, a lot of test and learn wouldn’t happen. Having the ability to prioritize test and learn is super important.
Then I also believe that there will always be more demand than there is capacity in the organization. You need to understand the capacity and where it’s going in order to make an eyes wide open, intentional prioritization decisions. First and foremost, required to operate. What does it take to operate our services? Second is, what is mandatory, compliance, regulatory, contract driven? Third, enterprise wide priorities, and how are you lining up capacity against those? Then last, product specific priorities. In that order, and it should be visible so that you know if you’re making tradeoffs, and what the implications are for those tradeoffs.
This is a tool that I’ve used, it’s called an A3-X. It might look really complicated. It takes a little bit to get used to, but once you’re used to it, it is a really good way to continuously prioritize and understand the capacity required to achieve the outcomes. This allowed us at Nordstrom to be able to see, where is our capacity going? How might we free up capacity if needed to unblock something that might be higher on the priority list? We use that for a couple different situations in order to make sure that we had our capacity aligned to the most strategic outcomes.
I talked about focusing on outcomes. I’m also a big believer in OKRs. I think the focus should be on creating the right structure and system to manage them, versus trying to acquire a tool to manage them. Shared OKRs are powerful, you can use those to get alignment. OKRs are not the same as KPIs, you need both. I think sometimes that there’s this myth that you have to have one or the other, when really you need both. OKRs should be what you’re improving. KPIs should be ongoing measurement and metrics that you’re using to understand the health of whether it’s your product or capabilities. I also believe data without context is meaningless. You need to be able to look at team level data, rather than aggregating or averaging across teams. An example is lead time. Lead time is a team level metric. If I rolled it up and looked at it across teams, it would not add value. It’s super important for leaders to not take a data point and jump to a conclusion. It really should be a opportunity to seek out and get curious, and ask questions.
OKRs and Leader Standard Work
Here are some examples. The OKR Confluence page I have used in my past to help explain OKRs and also to manage just being able to see them. Then having the right structure in place to understand the health and then make adjustments if needed to either the work or the OKR. The Jira board. This is something that I believe in as well. Most teams are using Jira to manage their work. I think leaders should use Jira to manage their work, because often we are the bottleneck when teams need help. It can take time for us to make a decision, or we get distracted too because we have a lot of work in flight. This is something I’ve used with my leadership team so that we can see work and workload balance, and unblock if something is critical and needs to be decided. This allows us to see and also track lead time for decisions.
Here are some self-service dashboards I’ve also used. The one in the very back is a way to understand capacity across teams and be able to see where you over-allocated or under-allocated, and where might you be able to balance if needed. The middle one is around team composition. I believe that it’s important and not a one-size-fits-all. Not all teams will have the exact same team composition, but knowing where you might have gaps. If you have a team that’s down to two engineers, it’s going to be really hard for them to have an on-call rotation. How might you help with rebalancing or investing in closing any gaps around team composition? Then, Employee Net Promoter Score, I believe in this as well. This is also from the book, Accelerate. Essentially, this is two questions, would you refer a friend or colleague to your team? Would you refer a friend or colleague to the technology organization? Then this gives me a way to learn if I have bright spots, or where I have teams that need help. Then try to understand what’s contributing to high or low ENPS.
This is a visual from John Smart’s book, “Sooner Safer Happier.” Any of his talks and materials online are worth reading and listening to. At one point in my career, I thought you had to choose agile or lean. This is a visual that I like to use to remind myself that it really should be about the work. The work should be the indicator for which methodology you apply, and making sure leaders are leading by example, not just in the words, but in the actions. I believe leaders should create focus, not chaos. I talked about that prioritization and focus. I think, if leaders are creating that, then there’s less chaos in the organization. I also love this final bullet, people, process, tooling in that order. I think it’s super important to always be focused on people first.
These are the resources and inspiration I’ve used throughout my career and continuously use. I truly believe that the community is here to share and learn from. I try to always be looking for how can I learn and continuously be inspired, and not be insular.
Questions and Answers
Shoup: How do you measure lead time? Let’s pop it up a level of like, why is lead time important? Because I don’t know that we’ve super motivated that.
Kissler: When I first started on this journey, I was not prescriptive. For me, it was just more important for teams to start understanding, what is it taking to deliver value to your customer? I’ve seen it in two different ways. At Starbucks, it was easy for us to understand, request came in from our customer, to we’ve released it into our customers’ hands. The underlying mechanism we use to measure it happened to be Jira. We had a way to understand the state of the stories as they were going through the backlog. We used that data to understand what it was taking. We did that at Nordstrom too, where we could look at variation and a bunch of different things because we had that structure. It also allowed for understanding the data quality of lead time, because if teams weren’t moving the features along, you would see that variation and it created an opportunity to just get better discipline in the system. That was the how. I’ve seen and I think the State of DevOps and Accelerate now say, from on dev backlog to in production as the measure.
Shoup: Because we’re talking about lead time, when you say a value stream map, just walk us through, what would that look like? Then I think a bunch of the other techniques that we’ll talk about.
Kissler: A value stream map is a technique and a practice where first you bring together anyone who is accountable for delivering that value. Say it’s putting a feature into your iPhone app. It’s like anyone who contributes to that, and it needs to be people who are close to the work, not leaders, usually. Not as easy to do remotely, but when we were not in that situation you would get everybody in a room, and literally Lo-Fi, up on the wall, Post-it’s that say, these are the steps that we take, and it should be reality. Not these are the steps we should be taking, it is what is really happening. Then you document how much process time, so how much actual time does it take. How much wait time, so someone’s waiting. Then delay time, and you start to see the total time. It is very fact based. Usually there’s not a lot of emotion. Definitely, eyes get opened really wide, because people start to see and some don’t even know that they’re handing off, and someone then is waiting or vice versa.
The other thing that’s powerful with value stream mapping is this concept, it’s a lean concept, percent complete and accurate. Which helps you understand, am I sending something to someone, and they have to send it back, because it didn’t have the data that was needed to actually complete the next step? I’ve always used outside help, sometimes that that translates into train the trainer. At Nike, we trained our continuous improvement team, so then they could do value stream mapping for us. That’s the concept, you essentially document it. Then you can problem-solve against it, because you see where all the bottlenecks are.
Shoup: Several people asked about the capacity question. There was one about people feeling awkward about redeploying their capacity and how do you deal with that? Then you mentioned and also the question mentioned the understaffing problem.
Kissler: One thing I’ve learned, and it is not easy, it takes heavy lifting, but once you do it, it becomes very natural and just part of the system. Reality is the work that the teams are doing every single day. Often, that’s not well understood, especially at a senior leadership level. When decisions get made, and I’ve been in this scenario, this is now our new priority, move teams and have them work on this. Often, that is not informed by the implications of that decision. You get teams, they move, they start working on that, and then there’s discoveries after the fact. What I leverage is, we have to know the capacity in the organization, and what the teams are currently working on. Not in a micromanage-y way, in a way to help elevate reality for the executives and the management team.
I believe that the number one thing is required to operate, some people call it keep the lights on, you have to have capacity against sustaining critical services. Then, most of us are accountable for compliance, regulatory work that has to be done, but often isn’t well understood. Then it should be these cross-company enterprise initiatives and priorities. Then that allows leaders to understand, if we’re going to take capacity from this and move it here, we are going to have implications that are these. Are we all good with that? At least it’s an informed decision. It’s not easy, and it takes discipline. I think once you get there, then teams see that leaders are engaging in the right way. You also see the understaffing problem, because sometimes there’s this assumption, and one of my least favorite words is fungible, that like, we’ll just move people around and magic will happen. Often, that is not an easy answer. You have to understand the complexity. You have to understand the skill set required. There’s a bunch of factors that go into moving capacity around. My approach is just to make that as visible as possible, and as clear to the decision makers, so they understand the tradeoffs.
Shoup: Turns out we’re not all like interchangeable cogs.
To lead with speed, how much decision making should be decentralized versus from a top-down?
Kissler: I believe that empowerment without context is chaos. I think senior leaders are accountable for creating context, intent, like this is the strategic outcome that we are going after as a company. Then empower the teams to organize against that outcome and achieve it. Create a mechanism or a system so that leaders don’t just say it’s a priority, go figure out how to get it done, but they engage on going to support the teams if they hit a roadblock, or they need help. I think the tops-down component is really clarity of strategic direction and outcomes, and true outcomes, not just, you need to finish this project. There should be something meaningful attached to it. Then, creating that structure so that teams can really be empowered. Then, my goal is to strive for decisions should be made as close to the work as possible, but teams should also have an escalation path for decisions that might need senior leadership help. When I’ve seen it done well, and when I’ve experienced it, a priority conflict no longer has to happen at the team level. The senior leaders are like, no, this is clarity of priority. Now the negotiation is happening less at the team level and more at the higher level.
See more presentations with transcripts
MMS • RSS
Posted on mongodb google news. Visit mongodb google news
Need a simple-to-use GUI to help manage your MongoDB databases? Jack Wallen shows you how to install Adminer for just that purpose.
MongoDB is a NoSQL database that is a great option for those needing to store massive amounts of data for highly available, scalable applications and services. Out of the box, MongoDB is managed entirely from the command line. For some database admins, that’s a fine option but for those who prefer GUI tools to take care of database management, where do you turn for this document-based platform?
SEE: 40+ open source and Linux terms you need to know (TechRepublic Premium)
One option is Adminer, which is similar to phpMyAdmin in that it’s a simple graphical interface for administering databases. Adminer doesn’t have the most modern-looking UI, but it does make the task of working with your MongoDB databases considerably easier.
I want to show you how easy it is to get Adminer up and running on AlmaLinux.
What you’ll need
The only thing you’ll need to install Adminer on AlmaLinux is a running instance of the operating system and a user with sudo privileges.
How to install MongoDB
If your instance of AlmaLinux doesn’t already have MongoDB installed, let’s do that now. Log into your server and create a new repository file with:
sudo nano /etc/yum.repos.d/mongodb.repo
In that file, paste the following:
Save and close the file.
Install MongoDB with:
sudo dnf install mongodb-org -y
Start and enable the service with:
sudo systemctl enable --now mongod
You’re now ready to install Adminer.
How to install Adminer
First, we’ll add the necessary dependencies with the command:
dnf install httpd mariadb-server php php-mysqli php-curl php-json -y
Start and enable MariaDB with:
sudo systemctl enable --now mariadb
Secure the MariaDB installation with the command:
Make sure to set a new password for the admin user and then answer Y to the remaining questions.
Log in to the MariaDB console with:
sudo mysql -u root -p
Create a new database with:
CREATE DATABASE adminer;
Add a new user with the command:
CREATE USER 'adminer'@'localhost' IDENTIFIED BY 'PASSWORD';
Where PASSWORD is a strong/unique password.
Grant the necessary permissions with:
GRANT ALL ON adminer.* TO 'adminer'@'localhost';
Flush the permissions and exit from the database console with:
How to download and configure Adminer
Create a new directory to house Adminer with the command:
sudo mkdir /var/www/html/adminer
Change into that newly created directory with:
Download Adminer with:
sudo wget -O index.php https://github.com/vrana/adminer/releases/download/v4.8.1/adminer-4.8.1.php
Make sure to visit the Adminer site to check that you’ve downloaded the latest version.
Give the directory the proper permissions with the following commands:
sudo chown -R apache:apache /var/www/html/adminer/
sudo chmod -R 775 /var/www/html/adminer/
Next, we need to create an Apache configuration file with the command:
sudo nano /etc/httpd/conf.d/adminer.conf
In that file, paste the following:
CustomLog /var/log/httpd/adminer-access.log combined
Restart Apache with:
sudo systemctl restart httpd
How to access Adminer
Open a web browser and point it to http://SERVER (where SERVER is the IP address or domain of the hosting server). You’ll be presented with a login screen (Figure A).
You’ll use the credentials and database name we created earlier, so adminer for the user, the password you created, and adminer for the database name. Once you’ve logged in, you should see the main window that allows you to manage that database (Figure B).
And that’s all there is to installing the Adminer MongoDB GUI application on AlmaLinux. It shouldn’t take you much time to get comfortable with using this tool.
Subscribe to TechRepublic’s How To Make Tech Work on YouTube for all the latest tech advice for business pros from Jack Wallen.
Article originally posted on mongodb google news. Visit mongodb google news
MMS • Steef-Jan Wiggers
Article originally posted on InfoQ. Visit InfoQ
Microsoft recently announced the NVads A10 v5 series in preview. These virtual machines (VMs) are powered by NVIDIA A10 GPUs and AMD EPYC 74F3V(Milan) CPUs with a base frequency of 3.2 GHz and an all-core peak frequency of 4.0 GHz.
With NVadsA10v5-series, the public cloud provider introduces VMs with partial NVIDIA GPUs. As a result, customers can choose a suitable sized virtual machine for GPU accelerated graphics applications and virtual desktops starting at 1/6th of a GPU with 4-GiB frame buffer to a full A10 GPU with 24-GiB frame buffer. Michel Roth, Azure Virtual Desktop Sales Lead EMEA (GBB) at Microsoft, explains in a LinkedIn post:
Next to these very powerful specifications, what’s special about these VMs is that with the NVadsA10v5-series Azure is introducing virtual machines with partial NVIDIA GPUs. This means that you don’t have to pay for a full A10 if you don’t need it.
The GPU partitioning is built on industry-standard SR-IOV technology providing a strong, hardware-backed security boundary with predictable performance for each virtual machine. The public cloud provider partitions a single NVIDIA A10 GPU and allocates it to six virtual machines. Each virtual machine can only access the GPU resources that have been assigned to it, and the secure hardware partitioning prevents unauthorized access by other VMs.
Other public cloud providers like AWS also offer VMs with Nvidia A10 GPUs. For example, AWS released EC2 G5 instances earlier, which feature up to eight NVIDIA A10G Tensor Core GPUs powered by second-generation AMD EPYC processors. Like the NVads A10 v5 instances from Microsoft, these instances are intended to accelerate various graphics applications like interactive video rendering, video editing, computer-aided design, photorealistic simulations, 3D visualization, and gaming.
The multinational technology company Nvidia stated in a datasheet on the A10:
The NVIDIA A10 Tensor Core GPU combines with NVIDIA RTX Virtual Workstation (vWS) software to bring mainstream graphics and video with AI services to mainstream enterprise servers, delivering the solutions that designers, engineers, artists, and scientists need to meet today’s challenges.
The NVads A10 v5 series are in preview on request and available in the US South Central and West Europe Azure regions. Furthermore, pricing details on these series can be found on the Azure Virtual Machines pricing page.
MMS • RSS
Posted on mongodb google news. Visit mongodb google news
Someone with a lot of money to spend has taken a bullish stance on MongoDB MDB.
And retail traders should know.
We noticed this today when the big position showed up on publicly available options history that we track here at Benzinga.
Whether this is an institution or just a wealthy individual, we don’t know. But when something this big happens with MDB, it often means somebody knows something is about to happen.
So how do we know what this whale just did?
Today, Benzinga‘s options scanner spotted 24 uncommon options trades for MongoDB.
This isn’t normal.
The overall sentiment of these big-money traders is split between 50% bullish and 50%, bearish.
Out of all of the special options we uncovered, 15 are puts, for a total amount of $2,102,045, and 9 are calls, for a total amount of $392,302.
What’s The Price Target?
Taking into account the Volume and Open Interest on these contracts, it appears that whales have been targeting a price range from $65.0 to $600.0 for MongoDB over the last 3 months.
Volume & Open Interest Development
Looking at the volume and open interest is a powerful move while trading options. This data can help you track the liquidity and interest for MongoDB’s options for a given strike price. Below, we can observe the evolution of the volume and open interest of calls and puts, respectively, for all of MongoDB’s whale trades within a strike price range from $65.0 to $600.0 in the last 30 days.
MongoDB Option Volume And Open Interest Over Last 30 Days
Biggest Options Spotted:
|Symbol||PUT/CALL||Trade Type||Sentiment||Exp. Date||Strike Price||Total Trade Price||Open Interest||Volume|
Where Is MongoDB Standing Right Now?
- With a volume of 741,099, the price of MDB is up 2.9% at $442.69.
- RSI indicators hint that the underlying stock may be approaching overbought.
- Next earnings are expected to be released in 63 days.
What The Experts Say On MongoDB:
- UBS upgraded its action to Buy with a price target of $450
- Barclays has decided to maintain their Overweight rating on MongoDB, which currently sits at a price target of $410.
- Morgan Stanley has decided to maintain their Overweight rating on MongoDB, which currently sits at a price target of $475.
- Credit Suisse has decided to maintain their Outperform rating on MongoDB, which currently sits at a price target of $650.
- Needham has decided to maintain their Buy rating on MongoDB, which currently sits at a price target of $362.
Options are a riskier asset compared to just trading the stock, but they have higher profit potential. Serious options traders manage this risk by educating themselves daily, scaling in and out of trades, following more than one indicator, and following the markets closely.
Article originally posted on mongodb google news. Visit mongodb google news
MMS • RSS
Article originally posted on InfoQ. Visit InfoQ
Good day folks. This is Shane Hastie and I have the privilege of sitting down with the culture and methods editorial team today, and we’re going to look at the culture and method trends for 2022.
Shane Hastie: I’d like to start, we’ll just do a round of introductions. We’ll start with our special guest we have Sandy Mamoli who’s not on the editorial team, but whose content has been covered quite a lot on InfoQ. Sandy welcome, give us the 2-minute who Sandy.
Introductions – Sandy Mamoli [01:06]
Sandy Mamoli: Hello everyone, I am currently in my third career. I had a youth playing handball, representing Austria at the Olympic games in 1992. After that, I realized I had to grow up, get a real job, and there was nothing better I could think of than becoming a software developer. That’s what I did for about 10 years in Copenhagen, Amsterdam, and Stockholm, and moved to New Zealand in 2006. And because I had been working agile for quite a while, I decided to not go back to previous ways of working, but to stick with agile and I co-founded a company that’s called Nomad8, that is doing agile work and agile consulting, and got at some point possessed wrote a book which if anyone should think about doing that is a lot more work than it seems to be.
I am now in New Zealand and have recently moved to the beach, and this whole working remotely or hybrid ways of working is absolutely growing on me.
Shane Hastie: Thanks, Sandy, and we’ll definitely explore some of the topics in the book. Doug, we haven’t seen you for a while. Welcome, tell us a bit about Doug.
Douglas Talbot [02:10]
Douglas Talbot: No, it’s been a very busy year. I guess I’ve been in technology all my life. I started off as a developer. I didn’t start off with handball, so obviously a different career path. And then I’ve been in tech roles for about 30 years now, about 20 years of that leading different technology teams across all sorts of different domains, including government, retail, robotics, banking all sorts of spaces. And I’m currently the CIO at Environment Canterbury in the south island of New Zealand, and I’m also the founder of a consultancy called The Adjacent, looking at organizational dynamics and how we can create better organizations, so that’s me.
Shane Hastie: And we’ll bounce to Ben, Ben Linders, probably the most prolific InfoQ writer across the whole team at the moment.
Ben Linders [02:58]
Ben Linders: Okay, thank you, Shane. Ben Linders, based in the Netherlands and these days, doing mostly workshops, training, coaching for an organization, focusing on finding ways to help organizations to improve. That includes some of the agile stuff, but I wouldn’t say it’s completely agile. It’s much more focused on bringing in the stuff that helps organizations to exploit whatever they have and become better on what they are doing already. And a lot of the stuff recently is around games gamification as a way to help organizations to really find their strengths and exploit their strengths to become better. And a lot of those games are also available online.
Ben Linders: I’m using them in my training, but I’m also making them available for other facilitators to play with them to download and to use them. So, sharing the work about these games and these coaching cards to the world.
Shane Hastie: And Craig Smith.
Craig Smith [03:55]
Craig Smith: Like others, I started my world in the technical space, although never actually meant to be in a technical space, so I actually went to university to become a librarian and somehow moved off in a different direction. Been around the agile field now since the early 2000s and really work in all sorts of different industries, helping people with both their learning and their agile journeys, based in Brisbane Australia.
Shane Hastie: And Raf.
Raf Gemmail [04:18]
Raf Gemmail: Hello everyone, similar paths to some of you are engineer for a very long time since the dot-com severe developer number four at booking.com many years ago, trying to do XP, going through to the BBC and other places where I learned to do it slightly better and became leaner, going through frameworks to finding leaner ways of working, came to New Zealand in 2013. And around that time shortly before we’d done a QCon gone talk with my friend, Catherine. I started writing for InfoQ and amusingly when I came out here, one of my favorite stories is that I discovered that the person who was taking me through my training, Shane, lived about seven minutes down the road for me here in New Zealand.
And the other funny thing is one of my first pieces that I wrote for InfoQ was actually an interview with Sandy Mamoli around self-selection, a piece, she did it at TradeMe here, so it’s nice to see all these familiar faces. From there, I’ve gone on to focus on tech coaching using agile & lean methods, currently head of technology at place called Developers Institute. I’m getting a lot of pleasure out of trying to help change people’s lives and bring new fresh people into the industry, get them across agile and lean methods earlier, create the people I would have wanted to hire who are experimental, who are open to change recognize that it’s a learning journey that’s continuous, and that’s why.
Shane Hastie [05:35]
Shane Hastie: And I’m Shane Hastie, I lead this band of misfits in the culture and method space. Like the rest of us, I did start off a long time back. And in my case, it’s a number of decades back in technology and programming. I’ve moved into leading teams and now leading teams that help people become better at doing stuff. My full-time job with a training organization based in New Zealand, but working all around the world back with SoftEd after a 5-year stint at ICAgile.
So, that’s us, but we’re here to talk about what’s happening in the industry. We’re going to come out of this, and we’ll produce the next written trends report.
We’ll have the technology adoption curve that we’re all very familiar with, but we want to let our audience know what is it that we collectively are seeing. And maybe let’s start with one of the big ones and Sandy, you touched on it. We’re all definitely experiencing it, hybrid work. What does this mean in 2022?
Hybrid Work and Meeting Hell in 2022 [06:42]
Sandy Mamoli: What I put down the word hybrid work is we used to come from all going to the office, then 2020 COVID happened, and we all learned how to work remotely. And what I see happening now is that we end up with spending our time partly remote and partly at the office, or partly in other locations. It is both remote, back to face to face, back to remote and people doing this mostly in a way that suits them.
Shane Hastie: How can this go wrong?
Sandy Mamoli: I can easily tell you my annoyances with it. What I’ve seen is when people decide we need to have face to face, and we also need to have remote time. So, how about we spend Monday and Wednesdays at the office? And what happens Mondays and Wednesdays is meeting hell, because all the meetings are all of a sudden crammed into a day or two and it is not fun. Everyone’s really tired. Other things that I find really hard and I’m not sure whether it’s going wrong or not, but what I find really hard because I do a lot of facilitation and training is that it is easy to do face to face. We have learned how to do it when everyone’s remote, but now you’re in a situation, where you always have some people in the room and some people remotely.
And I find it really hard or a skill that I’m hoping to master one day to cater for both groups of people at the same time.
Shane Hastie: Do you think it’s a skill to master Sandy, or do you think it’s just a mistake?
Sandy Mamoli: I think it’s a mistake. If I could avoid it, I wouldn’t do it, but I don’t know how to avoid it, having the balance of giving people a freedom to live their lives partially working from home and partially working from the office, without either creating meeting hell, or having those mixed environments. What do you think?
Shane Hastie: I’m like you really, really struggling with the mixed space, but it feels really hard to tell people no, everyone go and find a desk and sit on your own, so that you participate in an equal way across the team, or everyone come in for that day like you say and have meeting hell that day. So, I’m not quite sure what the answers are, but it feels like trying to force it to work hybrid is the wrong answer. What are we going to come up with in our organizations that’s going to allow flexibility, but good team dynamics is a big question. And I think part of it at the moment is actually looking at our environment in work.
Changing the office environment to accommodate hybrid work effectively [09:02]
Shane Hastie: And I’ve seen quite a few articles on this, people talking about the physical environment or creating remote offices where we can come and work in different ways, or collaborative ways. Maybe there’s something in what we can do with our old office spaces that we used to work with desks, but it’s a big unknown at the moment, but I feel like you it’s a mistake. And I just don’t know what the next steps going to come out are.
Raf Gemmail: I’m just going to add a plus one here this sense of it being a mistake. And I think the fact whenever you talk about anything hybrid, to an extent it feels like a transition. Hybrid cloud feels like a transition to being able to just work with the concept of a cloud, where hybrid just happens in the background. Hybrid workspace feels like a mistake, because it’s trying to put this noun in front of two things, but it’s not really the interface to the two things. It’s just a label that’s stuck on it. My view on this is I’ve been working remote since about 2019, and I feel that the journey we’re on… I put my hand up as a futurist, but the journey we’re on is one which is potentially in the next decade or so sooner, moving away from that physical presence.
And I used to post that. I used to think there was great value in people being face to face, but I think we get the same value remote. And I think there’s a tradition that we need to work away from, and there’s a new set of tools we need to build, but I do agree with you. It’s almost a label that’s put on there that says this doesn’t work. Hybrid, yeah, that’s controversial potentially.
Sandy Mamoli: I’m not sure I agree with you about the future, but I want to point out, I think it’s absolutely brilliant what you point out the word hybrid in this. It’s like hybrid agile which usually means you take the worst of both worlds. Maybe that’s what we’re doing at the moment, it’s the worst of both worlds and a world of pain.
Shane Hastie: Craig, you’ve been quiet through this little conversation, what’s your thoughts on this hybrid space?
Craig Smith: Thanks, Shane. Yeah, I certainly agree to what everybody else said. I think the thing about tools is what to me is what stands out. I don’t think we’ve got the tools that support the way that we want to work. There’s always going to be a want or a need, or people who don’t have the space to work effectively from home and having a place for them to go be.
There’s also a human element to this that I don’t think we can get away from the fact that as humans, there is that connection point that we need to have, whether that means actually physically going to an office because you take something like this recording, where we can all get together from all parts of the world is something that we couldn’t easily do even just a few years ago, but I think what we did in reaction to the last few years we’ve been through as we hobbled together a bunch of technologies that are okay. But from my friends on the call here who people like agile coaches for example, that’s a hard job to do remote. Leadership is hard to do remote, and we haven’t quite got to a tooling that allows us to do things, like check in on our teammates effectively.
The old thing about walking past somebody’s desk and just stopping and saying hello is so much harder in this hybrid world. I think tooling’s got a long way to go. And if that starts to get better, we might be able to start to see some things. So, those who are building tools, this is far from done.
Ways of work and culture handbooks [12:00]
Raf Gemmail: Organizations have been remote for a while I’m thinking of the likes of GITLab I’m thinking of a place like Octopus Deploy, these companies that are starting to… Atlassian is now fully remote and these places have one thing I’ve noticed which is a handbook. And they’re becoming handbook cultures where they start having processes or ways for people to work. Now, I know we’re about people and interactions over process and tools, right? But at the same time, these processes add clarity. So, working in a remote environment, I was initially like processes, do I have to to go to a handbook? But they do add clarity. The whole thing about coordinating people, I’m in an organization where we’ve been through that journey and trying to lead people remotely at first.
You’re trying to pull the physical world’s paradigm, right? I need to have a one-to-one with you directly I need to walk past you, or you have the one day in the office and you end up like chatting all the whole day of forcing meetings in. But as you go, you start using the tools slightly better, and that’s not necessarily the tool. It’s your use of the tool. I mean Team Topologies, they talk about how you structure your coordination, your communication spaces, right? Slacks, if they’re chaotic, people don’t know where to go for communication. If you structure them intentionally, people know how to reach out to each other. I reach out to my teammates digitally.
We engage, we have specific things for trust building and that’s not really the tool. It’s how we use the tool, so I throw that out there.
Craig Smith: That’s a good point, and I think the thing is in those handbooks what we don’t end up with is another Spotify agile approach here, where I go and read the book from Octopus Deploy and go I’ll do that here because the real challenge is if you’re a software company, this is I’m going to say easier to do. I know it’s not easy. But if you’re a government agency or a large bank and we’re also dealing with the culture of people who aren’t used to this. And of course, when you then mix in organizations that actually have people who physically have to be on site, because they have to actually remove a physical product, that’s where this becomes a lot harder. I think it’s still possible.
I think it’s absolutely possible to… we have to find a way through this. And I think this handbook culture and if you look at some examples of that, I think there’s some good guidance for that. Where we’re really going to succeed in this is when organizations start to solve some of those trickier problems.
Don’t try to take a human interaction challenge and turn it into a technology problem [14:08]
Douglas Talbot: I guess I’m living in an organization where the technology service that I provide supports hundreds of thousands of ratepayers, and hundreds and hundreds of frontline staff who have physical interactions with people out on the land and in parks and regional spaces and stuff. Suddenly, those toolkits and the ability to interact with those people and stuff is really, really important. We can’t just pretend we’re a little tech company doing an online product or a SaaS product. And I think that when we start crossing those borders, these techniques are effective shall we say. It’s very, very hard for me to get a bunch of those people onto a Miro and have a coaching session.
Whereas when we could go and visit their depot, it’s a lot more effective. So, I think that problem is nowhere near solved. And also I’m assuming Raf, you’re not trying to promote the sociological and psychological effects of not having physical contact and body language and such like is the good thing for our society. We’re seeing the effects of the COVID isolation on our kids. We can’t pretend that remote is going to answer those questions.
Raf Gemmail: I agree with everything you said there I do think we will evolve as we’ve done with every other methodology, how we do remote well and how we address the gaps in communication, how we address the imbalance of people who don’t have access to hardware. And I think as I said previously, we’re on that journey.
Sandy Mamoli: I think we need to be very careful, and what we need to be careful about is that we don’t take a problem that’s fundamentally one of human interaction, a problem of being we and having a shared goal and a shared purpose, and turning it into a technology problem. Technology can be helpful, but I don’t think this is a technology problem. And if we only talk about tools and how to use tools, I think we’re missing a bit. It’s important, but I don’t think it’s the most important thing. And I don’t know how to solve it because we are in this world of hybrid and we are making do with technology to aid us to find a way of working that suits all of us.
Variations on hybrid approaches [16:06]
Sandy Mamoli: And the best that I could come up with crazy idea right now is how can we have both without making this meeting hell or anything like that? Could we experiment with something that we have three months of going to the office working face to face and then three months, everyone works remotely and whoever wants to travel or work from Thailand or the beach, that’s cool. Three months later, we go back to face to face. So, maybe it’s the time that goes like peaks and troughs in terms of face to face and remote.
Raf Gemmail: I particularly like the Thailand.
Co-working over meetings[16:38]
Ben Linders: I think talking about meeting hell, and I think one of the first thing that you should actually look at is why are we doing those meetings, regardless whether we’re doing them on site or remotely, because I’m really trying to abolish every meeting there is. And if I want to do something together with people, I’m going to turn it into a co-working session. And we can do that on site, and we can do it remotely, working with the shared purpose, working on a shared object. And the easiest thing you can do already is work together in the Google Doc or anything. But at least being working together and creating something, that’s going to give a completely different turn to collaboration.
And you can do it remotely, you can do that onsite, but most of the meetings are actually worthless because there are meetings that makes them a waste already.
Sandy Mamoli: But how is co-working not a meeting? It’s people getting together doing something and talking to each other doing its meeting.
Ben Linders: Well, I think that the difference is you’re working together on a result and you’re working together, and that’s the thing you touch upon already on that shared purpose. You’re together there to create an outcome, not to just discuss something, but you’re working to produce something, and that’s what makes a difference.
Shane Hastie: I’ve taken in conversations that I have with people that there is a difference between a collaborative working event and a meeting. A meeting in my mind is typically something that is done where a group of people make work and assign work to other people, whereas a co-working session, a workshop, a collaborative event is a collaborative event where two or more people get something done together. If we take this stance of getting stuff done together, versus the traditional meeting, often it’s not collaborative, it is a manager in the room telling people what they want them to do. Maybe if we’re really lucky asking do you disagree with me and not really listening to that either.
But if we can get to that true collaborative, cooperative, change the focus of these events from the one-way conversation to true purpose-driven working on something together. Craig and I have been privileged in our day jobs over the last couple of months. We’ve been doing a lot of work together. We’re doing it remotely, and the time that we spend for me has been incredibly valuable, and I hope it has been for Craig.
Craig Smith: It’s interesting Shane that I feel that attitude to interaction has not been the meme even before the COVID remote game. Whenever you dragged individual contributors into a gathering of individual contributors and said let’s figure out a strategy together, let’s design an architecture together, let’s discuss our performance together, people assumed that was a meeting. And I think that that term has got attached to work where you are trying to forge forward, create products, decide, learn together. And all of those things got called meetings and most of them weren’t one-way delivery of information, or assignment out of stuff.
In fact, I’m trying to think of the last time I was in a “meeting” that was one-way delivery – it just doesn’t happen anymore in my world, and yet everyone else calls those scheduled gatherings meetings. And because that term has been attached to them, people are pretty anti-them. There’s a real negative meme there, and I don’t know how we can get past that. I don’t know how we can re-badge or something to get the idea that you’re passing on, because I think that many of them are actually healthy interactions.
Drawing from domain driven design – being deliberate and selective with the language we use [20:10]
Raf Gemmail: I’ve done just what Shane said rephrasing it. So, there was a government project a few years ago, many years ago now where I first tried this which was renaming things workshops instead of meetings. And you go through the inclusion, but I’m a big believer in domain-driven design, right? What you call it is how people see it, how they visualize it, how they build it, how they interact. If you’re selective with your nouns, you’ll get the right outcome. We were having the same conversation in our work thing yesterday around health and well-being. You take a concept, like a sick day, that’s almost got a negative connotation. Can you flip it to a well-being day, or something like that to allow people to feel safe in utilizing that?
Similarly within your local context, within your organization, you can be selective about the nouns you use for those meetings. And it might be a small win. It may not work there, I don’t know, but I do think being selective about what you call things can have an impact.
Ben Linders: I agree, labeling them differently, labeling them as a co-working session and making clear that what you want to have is not a meeting where you go out and where you have to do work, but that you have actually done the work when you leave the meeting. You’ve worked together and you’ve produced a result, that makes your time much more valuable.
Sandy Mamoli: I think this is hugely important for our group, and I’m glad we cleared that up. I’m super loose on the definition of the word meeting and I’m with Shane, yes, I should change that and it’s helpful if we are more restricted, or precise with the use of our words. Do you think that other people outside our circles would care, whether we call it a meeting, a workshop, or working session?
Craig Smith: I was talking to a group about this just this week because I was running a facilitation class in this type of thing, but I think it comes back to the problem without tooling. Because as soon as something ends up as an Outlook slot, that that’s the first issue. The thing I always deal with folks in the class is simply they come to some facilitation class. It’s their first perhaps get together or after they’ve done agile fundamentals, for example, and the thing I often get is I love this agile thing, but there’s way too many meetings. And you can bring up something just simple like the scrum diagram and go, “Well, there’s only four of them.” There’s maybe half a day to three quarters of a day.
Facilitation is an important skillset that is often missing [22:13]
Craig Smith: What are you doing with the other 98% of the time, and they all agree it’s work. And they go, “Well, how do you make those sessions work?” I think the tooling doesn’t help us, but also the facilitation doesn’t help us. Because when we do get into those rooms, do we have the right people to make the decisions? And this is our problem because again in the workplace, we could just call the Larry down the corridor and drag him in and go, “Larry, we’re going to make a decision.” As soon as we start being hybrid, we have to intentionally then get into their calendar. We realize they booked somewhere else we go, we’ll have another meeting and all of a sudden, we’re back in that same process.
So, naming is one part and absolutely agree with it, but also I think we have to intentionally think about getting back to some of those basics about the facilitation and having an agenda and all those things without also over engineering them.
Shane Hastie: So, how do we do good facilitation? And one of the things that we put on to our trends report last year was the need for facilitation skills. What are we seeing? how is that improving?
Facilitation needs to be independent [23:09]
Ben Linders: Well, I think one important thing about facilitation is that you want a facilitator to be independent. You want a facilitator to be focused on the group, on the culture, on the interaction between the people, and not on the outcome. The facilitator is focusing on creating the best condition for the people to work together. And if the best conditions are there, the best outcome will arise from that meeting. And this already starts when you plan something to work upon, and somebody’s going to pick up the role and facilitate. The first check for me is then okay, can I be independent enough to lead this group, to guide them, and to get them towards result, and will I be perceived as independent enough?
Because this perception is even more important. If people feel like no, you’re leading us towards a certain result, they’re much, much involved in the stuff to work on right now and you’re much involved on getting a kind of result out of there, then this independence is not going to work. So, it’s about how you’re perceived as a facilitator to get the right results.
Douglas Talbot: I hadn’t even really thought about it until you raised the question, but I realized that I’m seeing that a lot as a problem at the moment. The amount of time that we’re on these interactions in a remote world now, and people are not used to the interaction patterns and the conversation becomes stilted and people talk over each other, et cetera, et cetera and I’m finding that there isn’t the skills in the team to lead this, and actually a lot of the skills are required by leaders, whether it’s some kind of architect trying to gather devs to a common conclusion, or whether it’s management layers talking about strategy.
Remote and hybrid facilitation needs very different skills to in-person facilitation [24:42]
Douglas Talbot: Often, there isn’t an independent in the room quite often because that just wasn’t people’s habits pre-covered, and now the skills are actually not up to it. Most of our leaders have never even touched Miro it’s a new game for them. They don’t know what to do, they don’t know to prepare beforehand. They’re turning up to the meeting and just going hoping it’s going to happen. I think there is a really big shift in learning needed here if we’re going to use this mechanism more.
Sandy Mamoli: I absolutely second that. It’s a totally different skill set and I facilitate a lot, and I had to learn that things that work offline or in a room don’t work online. It’s a totally different way of having to learn how to manage energy, how to get people to talk. Dealing with a reality where people are tired way earlier, a reality where they take in half of what you say, how clear you have to be with instructions, how you have to repeat them and give them in writing and so on. Are you going to play with synchronous and asynchronous communication? I think that’s really, really different and the other thing that’s really different is just mastery of technology.
I find that recently, I had to learn a lot about almost producing, learning the tools like both Zoom and other tools how to do breakout rooms, how to use virtual cameras, how to make sound good, how to have my lighting in the room to come across okay. So, those technical skills as a facilitator are actually quite important too, and I’m not sure where other people are at because I’m quite biased because I’m teaching that stuff, but I also realize that there’s a lot of learning needs around.
Shane Hastie: How do we help organizations see the value in this as opposed to seeing it as an overhead because when we were in person, we didn’t have those “extra cost, extra time” of having this neutral person. I want to go meta a tiny bit for our audience. We’re using a tool that actually has a raise your hand and I’m noticing when people have what got something to say. Craig, you just raised your hand.
Roles and skills are not evolving at the pace needed [26:48]
Craig Smith: Well, I think we’re talking about this role. We have these roles, and we’ve had them for 15 years. We have roles like scrum master for whatever better term and product owner, as well as leaders that are perfectly suited for this role. By definition, if you dig into the words around particularly that scrum master role that comes from scrum, I mean that is about facilitating the team that’s exactly what that role is, but unfortunately the folks that are doing that role. And I’m seeing this particularly in small organizations, that care typically isn’t taken.
It’s just whoever’s the right person to do it and in large organizations, it’s just this person sitting over here often is the person who gets to go on a 2-day training class to learn the basics of some framework, and then it’s supposed to lead a team. If we want to become more mature in this space, those roles, we need to take those more seriously because there’s an awful lot of investment in organizations to having someone sitting there with a tag of scrum master and a tag of product owner, but what I’m starting to see is that as the organization starts to mature and expect more from its teams, those roles often aren’t keeping up with that pace of change. So, there’s a lot of good people there, right?
Don’t get me wrong, but for every great scrum master or product owner I come along, now there is a whole pile of others that are just struggling. Either because they don’t necessarily want to do the work, or they’re not giving the ability or the time in order to improve their craft.
The difference in high-maturity teams [28:07]
Ben Linders: To add to this, on the other side of the spectrum, what I’ve seen really high mature teams people working together to realize something. And what you actually see is that everybody in such a team has their facilitation skills. And depending on what they are working on, depending on what they would like to do, one of them will step up and will say, “Let me facilitate this.” And I’ve seen this with teams that I worked in, where I was actually the share of a group and when somebody said, “Okay, but if we’re going to do a strategy session, I’m going to facilitate this session because I’m much more independent. I can be much more independent in this role, and I’ve got the skills to facilitate really around round setting. I know how to pose it, what kind of questions to ask.”
Instead of having one person being the scrum master for the team and being the default facilitator, if you’re a high maturity team, everybody can be a facilitator. And you’re just going to be facilitating on the fly, whoever is the best candidate to facilitate at that point in time. It’s a skill that everybody has.
Raf Gemmail: I second that. I’ve been in those teams, but also been the teams where Craig was saying earlier, you can have the lack of the role be a void which everyone is trying to fill. And then you have those meetings where there are no outcomes. I think there’s this need for intentionality around making sure you’ve got that competency. Like any other competency in organization, if you’re having meetings or workshops or whatever it is without the right outcomes, it’s probably a smell to the organization that they need to get the right people in. One thing I was going to throw out those there, there’s another benefit from building these remote facilitation skills if you can do it right in a remote context is inclusion.
Remote work can improve inclusion and support greater diversity [29:41]
Raf Gemmail: We’ve been experimenting with putting boards up early, right? Instead of waiting for the day, give people time to think about the problem at hand and contribute before the event. And that means that you’re getting wider feedback from the group, there’s greater diversity of thought. And if you can start doing those things right, you might see other benefits making up for things which are potentially lost. The things are potentially lost, I’ll throw it again as a futurist, we can make these canvases and these environments very interactive. We can make sessions interactive. We can make them suitable for synchronous feedback. N one’s going to wipe the board.
Shane Hastie: I’d like to just move us forward a tiny bit, but I also want to tackle the futuristic the technology. Where’s the metaverse in this? Where is immersive virtual reality? Is that where we’re heading? Is that what we need, and is that on the far, far left of our adoption curve, or are we not even there yet?
Immersive technologies and games are starting to become available [30:31]
Douglas Talbot: I’ll avoid specifically the metaverse, but I do think that one of the things I saw literally near the beginning of the COVID game because I was in England for the first months of COVID and pretty much we lived 100% remote for 12 months because you couldn’t go out. And one of the things I did see innovated in that time was people using Fortnite as an environment in which to teach agile coaching sessions. And they were arranging the pizza game kind of equivalent teaching people how to do flow management and work in progress limitation and stuff, but actually in a real-time environment inside the Fortnight, the game. And they’d set up their own assault courses and problems to solve as a group and things like that.
And I thought that was a really, really neat of bringing people into another space. And it wasn’t VR, but it was taking people into a place where they can act more in a natural not 2D land. And I thought that was really, really cool.
Raf Gemmail: I’d look for the name of it there was a friend of mine at Assurity. At the start of COVID, he’s got an Oculus Rift, and he demoed literally like this 3D space with a whiteboard and such. No one probably used it. I’m sure they’re like 10 people on earth, but it looked pretty nifty and that tech is out there. I love the idea of Fortnite or another 3D engine becoming an interactive space. In about 2007, I went to a java conference and Sun was still owned it at the time. And they were demoing a virtual workspace, and I’ll never forget this. they had 3D avatars from different offices. They had a mix of 3D avatars and a video link to a room, and it looked ridiculous.
And I never saw it again, and I don’t know what happened to it, but I think there’s a transition through time, where a lot of these ideas were seeded. And the only reason we’ve got hit COVID and we can work quite well now is many of these things have evolved to the stage, where I can speak to you without high latency. I’m actually coming through Starlink in space and I’m living in the middle of nowhere, and I can do that now. I couldn’t probably have done that five, 10 years ago because satellite was high latency then. And there is this journey, but I love the Fortnite metaphor.
Sandy Mamoli: I absolutely love this, and I’ve got a feeling that we’re going to be left with two things. And one is face to face, which I think is irreplaceable and the other one is having something that’s absolutely immersive like an equivalent of metaverse or holograms, or there is going to be the Teams and Zoom meetings. I don’t think there is room for both of them. I think one of them is going to win, and we’re going to have immersion plus face-to-face, or we’re going to have the current type of Zoom plus face-to-face. And maybe that’s when companies are going to diverge a lot. There are the more cutting edge ones that are taking input from the gaming industry, and then there are the other ones that are stuck in all the technology that is very much 2D.
And I think it’s going to be super interesting which one of those two we’re going to be left within three to five years.
Shifting from Individual performance to team performance [33:17]
Douglas Talbot: I can jump in with a slight change in direction here Shane, and this brings facilitation as a skill set in our leadership and to get teams together and this 3D world and the metaverse and such like together, is that what we’re looking for is arguably more effective teams, more effective individuals, more effective organizations. And one of the things I’m seeing is that the world is still very, very dominated by thinking individual. Almost all of our performance management and all our leadership courses and stuff are focused on how do I do one-on-one coaching using say grow model, or something with one person, but they’re not teaching leaders how to deal with a team.
And what we’re talking about here is how do we deal with a team and arguably, how do we deal with a bigger community using technologies, and how do we make that interaction of multiple people at both small team size and large scale size more effective. And I think that the world has to start recognizing that the sociology of large-scale organizational interaction, the sociology and the psychology of small team interaction and the psychology of individual one-to-one and stuff are very different patterns and skill sets. And we need to have all three of those starting to be first-class citizens for our leadership and for our organizations. And that’s not happening well enough yet, so it’s all still one to one.
Raf Gemmail: I’m just wondering about descaling, right? We’re seeing that again taking this idea that if you have too much stuff, there’s too much cognitive load. It’s harder to manage, it’s harder to dissect. We’re seeing these trends around descaling. We’re seeing this move away from the drive to grow, to grow, to grow for the sake of growing, to perhaps being more intentional about goals and targets, to be more intentional about well-being in an organization. And when I hear that I’m just wondering, you talk about the sociology of the large enterprise. And I’ve been in those large enterprises, and they’re very different beasts to where I am now, which is more rapid decision startup culture.
And I remember the anecdotes around general electric and others having breakout teams and small innovation organizations. And I do wonder if the way forward is less of the large and more of the new. That’s completely speculative, but there’s a thought though. When you managing too much complexity, the best way to manage it is to slice it. I don’t know if our industry, if capitalism in general, or anything else will support that descaling at large, but you break a big problem down.
Shane Hastie: Sandy, if I can put you on the spot. You mentioned more sales of the book, you’re hearing more people asking you about the self-selection. How does self-selection tie into what we’re looking at here?
Team self-selection and empowerment [35:50]
Sandy Mamoli: I think there’s a bigger trend which is towards trusting people more to make decisions if they’re close to the information there is a loss of control for management to tell people what to do. While at the same time, people are going actually this is a good thing. So, I think there’s a tendency to trust people more, to choose who they want to work with which is both from the goodness of people’s hearts, but probably also out of necessity is at least my theory of why there is a big uptake at the moment and potentially also because it’s something that is easily so replicated online. It actually the same principle the same facilitation techniques make it possible to choose your physical team as your remote team.
Shane Hastie: Ben, what are you seeing in terms of you mentioned gamification is a trend? How are you seeing that flying in here?
Gamification to encourage collaboration, creativity and performance [36:42]
Ben Linders: Well, I think the big benefit I see with gamification is that if people start playing games, not doing that together, they do that voluntarily. They do the game playing because they like to do it. It’s a fun activity for them, but they’re feeling much more engaged into this game and to do stuff in there. And that sets the stage for everyone to bring in the best they have, and to see what those best combined what kind of result that they can bring in there. And I’m talking here about open-ended games. I’m not talking about closed games where people have to go to a couple of steps to get to what’s result, but an open-ended game.
And when I use gamification in my workshops, I use it to set up an environment for people to collaborate around a certain thing that I want to teach them, that I want them to experience and then just to see what happens in there. And I’ve actually seen teams playing one of my games and then bending the rules like, “Okay, the rule was that we couldn’t take that card, but actually we would like to take that card, but that card can help us what result. What if we change rules?” Do it. If changing the rules helps you to get the result, then you actually go into a meta level looking at how are we working together? How are we accomplishing that result?
“Hey, we need to change our way of working to get that result out of there.” I think gamification works on this invite only basis and engages people in there to bring in the best in there. And actually, it combines with the self-selection. A lot of games that I do certainly if I play with multiple teams, I use the self-selection in there and I ask people to self-select into teams for a certain topic, for certain exercises to work together. And it’s always interesting to see what happens in there. And I never know upfront what’s going to happen, but I know that whatever result is going to happen if people self-select into a team and start work on something, it’s going to be the best result that you can get, because I really, really enjoyed them to do because they had a choice.
Shane Hastie: Last year, we put in our innovator space the discussion about humanistic workplaces. How has that happened over 2021, and what’s it looking like going into 2022? Are we getting better at that?
Humanistic workplaces are not making much headway [38:54]
Ben Linders: I think the quietness is already making clear that we’re not getting better with that. I think it’s a couple of small organizations who are experimenting with this and are really focused on the individual needs of people in their organization and giving space to that. The majority of the organization probably still doesn’t have a clue how to deal with this, at least that’s how I perceive it.
Sandy Mamoli: I would agree. It’s definitely early stages, but I do think there is improvement, but I noticed the division is getting bigger, the differences between companies who manage in the way that they trust people, they take their employee, happiness, mental health seriously, and the companies that don’t give people agency and control over their days. I notice it every day. When I work with different clients, the type of organizations where people are asked to schedule their meetings when they want, take time off Zoom and make sure to work with people, work by themselves and not manage their days with breaks and beach walks and so on.
And then there’s the other type of companies where you just see people’s calendars and they are on screen from 8:30 a.m. to 5:30 p.m., back to back meetings and no break. And I think that division, what I sense is getting bigger.
The rift between good and bad organisations is getting larger and the impact is hard [40:10]
Craig Smith: Yeah, I think Sandy said it all that it comes back to all the things we’ve been talking about in this entire podcast is that I feel that the divide is now starting to grow. It used to be they are using new ways of working or not. Everybody is now professing that they’re doing some sort of this, just because they happen to have brought a couple of licenses of Zoom or Slack teams on everybody’s machine. It’s typically the way to do it, but the way we lead those organizations, there’s a big divide. The tooling that we provide, there’s a big divide. The quality of the work and how people collaborate, there’s a big divide. And I think I’m seeing that divide get even worse.
And one of the things that I popped into our notes here is that I actually see particularly large organizations, the IT department going backwards in a lot of cases where the IT department is now just becoming the, “Well, tell us what you want, put it in a document and we’ll go and make this thing happen,” and removing all of the collaboration and the things that we’ve built up over a number of years going backwards. So, this divide does worry me and I think we used to think that maybe well, it would be the customer would vote and go somewhere else or whatever and there’s a certain extent to that.
But unfortunately for the folks that are left behind and for the customer who’s actually has an expectation of product, I think this is going to get worse before it gets better, unless we are able to jump in as a community and fix this issue.
Raf Gemmail: I would reiterate as well, there is a divide. If you look at the world, there are trends and experiments. France experimenting with variants of a 35-hour week. You’ve got companies which are talking about potentially doing four day weeks, giving people the space to recover. I’ve seen anecdotes about how in some, and this is another software bias thing again. Perhaps for software industry as opposed to other places, teams which are performing well at remote potentially needing that space to be able to recover and stay healthy mentally. I think there’s something happening, but I think it’s really at that innovator level still.
And I don’t think it’s necessarily spread, which is sad because we’re in the time where this is needed more than ever, right? I have people, I am related to who have COVID right now back in Europe, and the people getting it up, they’re all from here. And people are going through probably the hardest mental health challenges that I’ve seen in my life. Also, given the geopolitical events, there’s so much uncertainty there and we need to be able to create those environments that are safe, and where people are invested in, and where we have those humanistic workplaces where people can be themselves.
And they can say, “Look, I need time out.” I’m lucky I’m in a place where we can take mental health days and where we’re looking at those problems, but I know it’s not the same everywhere, and that’s a shame given what’s going on in the world.
Douglas Talbot: Doug, you’re inside what we would look at from the outside and say is one of those traditional bureaucratic organizations. What are you seeing?
Yeah, I would say that my life is definitely back-to-back meetings and not great flexibility. And I think that it’s generated from what I see in all of the organizations around me is an inability to say no and to limit whip fundamentally as an organization. As a government organization, people feel like subordinate to central decisions from central government. And I feel there’s no way to say we’ve got too much on, that is not a legitimate answer to your central masters. And I think that we get that happen in big conglomerates, telcos, banks, insurance. I think this is the same pattern where the higher hierarchy have no concept of the cost on the bottom of the chain in terms of work of progress, context switching, and all of those flow problems.
And until they start to recognize that changing 10 pieces of legislation within six months, and what that’s going to have is a flow-on effect across say New Zealand government. And they consider that as a bit of systems thinking before they go and do it where we’re stuffed, but that’s just not part of the government way, or the big corporate way. So, we definitely live inside that. We’re literally having this discussion now. I guess some credit for me being a radical in the middle of the organization and going, “Actually, we need to think differently if we’re going to be more effective.” And everyone in the organization recognizes it. Everyone can see it, everyone can see we’re acting this way, and everyone wants to change it, but the pressure is unrelenting.
And it’s pressure they can’t really control because they don’t own their own lives. They don’t own their own lives the same way and maybe a 50-person product company might. So, it’s a real conundrum for these big organizations.
Sandy Mamoli: I just want to say I so feel for you and I so absolutely appreciate that you’re trying to do something about it, because I think only people in your position in a CIO leadership position can change something like this, because one of the trends that I noticed is that people spend lots and lots of time on training and organizations pay for trainings. They give people time to go to training, and then we have people there who say, “This is awesome, this is amazing, this is an amazing tool, but I can’t use it because we don’t have time. I wish I had to time to do this. I wish I had the time to prepare for this, or use the tools that you’re giving us, but we can’t because we don’t have time.
So, we’re not allowed to.” And that’s exactly those people that you’re talking about I think, and I just want to say thank you that you’re trying to do something about it.
Have the conversation in large organisations [45:18]
Douglas Talbot: Fingers crossed, yep. There’s a good healthy conversation happening. And I think this is the interesting thing for me is that the excitement because we’re having that conversation is huge, and I think that there’s a lesson there for leaders across all of these more bureaucratical traditional, or large organizations where this problem is that actually your people are probably waiting and eager for that new humanistic world and for a realization that a recognition from the leadership that we can’t do everything. We have to actually be more clever about the way we manage work and prioritize. And then we’re going to be far more effective if we do do that. Yeah, there’s a real excitement in Environment Canterbury at the moment about trying to take on a new working world, and so fingers crossed.
Shane Hastie: Ben, what are you seeing in Europe?
Ben Linders: Well, coming from a country who’s famous for the meetings, I think back-to-back meetings is something that I see a lot in the Netherlands. And I’m lucky to be a one-person company, and not having those meetings. And the other thing that I see, what Sandy mentioned, on being able to pick up stuff from training and to use it in your environment. I think the trick there would be to make it smaller, and that’s something that I’m doing more and more with the companies I work with. When we’re discussing workshops, I’m looking at okay, let’s just focus on having one day of workshop, maybe two days max, and then pick out some stuff and start working on that.
It doesn’t work to have more days of training because in one or two days, I can give you enough stuff to start working and to start changing something in your organization. So, let’s focus on what you want to have in those two days, what’s the most important stuff that you need right now to work on, and then start applying that in your organization, and make space for it to do it. And if it doesn’t work, it doesn’t help to do more training. You need to get the change going.
Shane Hastie: I think we’ve got a lot of alignment around that that we’re not seeing as much as we would like, but there are glimmers of hope. The next topic I’d like us to step into is ethics and professionalism. What’s happening in our industry, and I’ll think this into some of the tech for good as well, but ethics professionalism and tech for good, how are we doing?
Craftsmanship and professionalism are challenged [47:23]
Douglas Talbot: I think there’s a very big difference between professionalism and ethics, but just personal thoughts, and I think craftsmanship is my way of maybe describing professionalism. Care for what I’m doing as a professional in my trade, and I would say that we’re seeing that degrading lots over the last five years. I’m seeing small snippets of really enlightened pockets of people, the ones that are really participating in say open source, or in the small companies where they’re wanting to innovate tech together and stuff, but I’ve recently been involved with a few early phase organizations and walked in, and found developers who don’t want to test.
And developers that have never even heard of TDD, or never even considered whether or not they’re creating their own failure demand when they release to production without thinking about what they’re doing. So, I’m quite disappointed in the direction of professionalism for me especially in the software development community. And I think that the days… when I think it’s because of the speed at which the community has grown, and now we’re seeing it with the low code as people have mentioned in our notes coming in.
Just the mass expansion of, with 10 times the number of people in tech that we were maybe years ago, but actually the same number of people are still coming out with arguably where they’ve actually taken a professional degree in that thing, and thought about the structure and the way that they do their work. Most people are just jumping into it ad hoc, and they’re not taking the time to actually educate themselves on good practice, or read a book like Design Patterns or something. I’m actually seeing that happening a load less. I’m finding a lot of senior developers who really don’t know what they’re doing in my opinion, and that’s really poor. I’ll go with that one first before we get into ethics, but I think it’s a different thing.
Coaches stepping into domains they are not qualified to work in [49:08]
Sandy Mamoli: I want to have a rant too. If Doug can get rant, I can get one too. Those about agile coaches because that’s what I do. And I think it’s extremely well intentioned, but I heard our coaches say things like, “We’re really done, people are struggling with mental health. What should I do to help them? How can I make sure that people have a workplace, and have the mental health intact? And how can I coach people through their lives to be happier, to cope with things?” And my rant is that I think it’s unethical to not be humble enough to realize that you’re not qualified. If someone needs professional help, send them on or if you want to do this, get professional education to do this.
And I’ve seen so many times, been in my own company, people are really struggling in lockdown, what do I do? I was like, “This is not your job, get them to talk to someone who knows about mental health.” And personally, I think it’s well intentioned, but unethical to overstep those boundaries, rant over.
Shane Hastie: On that particular topic, I’m in the midst of doing a program on mental health first aid. The whole program has actually been offered to professions like chartered accountants. I’m an ICF coach, and the message of that is you can’t help people, but what you can do is point them towards this is the resources that are available. And this concept of mental health first aid, I’ll put the links in the show notes because it’s a really powerful program. But Raf, I think you wanted to say something and I hope it’s about how you’re educating people to be better.
Raf Gemmail: Very much, it’s intentional for us. I just wanted to touch on the health thing I agree with Sandy about the fact that there’s coaching different domains, right? And people have different proficiencies, and you can do more harm than good if you start getting into trying to help someone well-intentioned, but without the right skills. At the same time, you can also look at it as another capability. Now, we talk about capabilities that your organization needs. In our space, we’ve brought in someone to handle that well-being, because you need someone who is an expert in that realm. And that’s something I’d probably recommend the listeners to think about.
Because if it is a genuine need and you can resource for it, or you can provide a person for it, it’s probably worth doing. On the other side like responding to Doug there, I’ve seen exactly the same as you, right? I went through 2000s and I have still got my gang of four book there and Eric Evans, and all of these things which I feel helped me along my engineering journey.
And I’m in a place now where a primary question, the many people have been in industry who built software in my team. And our question has been, what is it we’re looking for when we’re trying to hire people? And it’s not always the grad who comes out, right? I don’t think they do do the university.
Developer education is evolving [51:52]
Raf Gemmail: I don’t think they necessarily look at the gang of four in university. So, the question was what are we looking for in terms of competencies, and what would we be hiring in someone who’s starting that journey? How do we give them the learning skills to go along that journey? I helped shape a program that we’re delivering to learners remotely, fully remotely which takes people from client-side development, through to server-side development through to understanding product development, asking questions around their test cases and scenarios, how to validate and shift right, how to test early and shift left. And it goes on to touch mobile development and machine learning and other things.
And it’s very intentional in trying to create those people that are missing in the industry. That desire to learn, that desire to be really on a continuous learning journey, and also to start from the perspective. I was taught waterfall as probably the rest of us were at uni as a software engineering practice. And I think I often apologize to the learners that I am the reason you may go into an industry where people will hand you a document that will tell you exactly what to build, and you’ll discover it’s not the thing you’re supposed to build at all. And it won’t solve the problem. We’re trying to get people to think about that know what they don’t know, validate often be experimentation driven. I’m doing that.
There are other boot camps out, there are other universities. I was involved with another organization which was doing that in Europe a few years ago, and I think I’m hopeful that what we’re going to see in coming years, even now starting out is new diversity coming into the industry. People with new perspectives, new backgrounds, people who don’t fit the old cookie cutter, who can help challenge teams and say, “Hey, why don’t we look at this a different way,” but still value the fact that there is an engineering discipline for them to be familiar with, an engineering discipline that’s evolving still, right?
I’m not going to go off and tell everyone, “You need to follow these architectural patterns” because they may not be valid anymore in a stream-based world, but I want them to think about what good professional skills are. We’re doing that and I’m sure many others are.
Shane Hastie: Craig, can I ask you for your thoughts on either of these?
There is often a vacuum in leadership [53:53]
Craig Smith: Yes sir. Sandy and Doug rant, I’m going to go on my rant then and say yes and to what everybody has said. There’s two past this. I think our leadership in organizations has a lot to answer for. I was talking before a little bit about the IT going backwards. And what I’m seeing is that that is due to a complete lack of leadership in some places. Some places are very good, okay, but again this is divide. I was just recently in a place where the engineering manager didn’t know a lick of engineering, was hiring for the wrong people, didn’t talk to the engineers about the code, but on the same token, would be complaining about why things aren’t working right and it falls flat.
He wasn’t setting those expectations in this particular organization, then allow them to go do good things. And this stuff doesn’t happen magically. The flip side to that however is what Raf was just talking about is that most of us that came through that waterfall culture, and most of us have been around on this journey for some length of time was that at some point, we realized that TDD, Kent Beck writes a book and we read it we go, “That’s a really good idea,” or we read the extreme programming, or we saw something like DevOps and went, “This is a really good engineering practice.” Yeah, the amount of organizations who I come across who don’t even have good version control for crying out loud.
They want to say we’re putting in a DevOps pipeline, but they don’t even know to put their code into version control is just nuts. So, there is a professional angle, and this I think all comes back to the WIP thing that we’re trying to do too much stuff, so therefore what gets thrown out? What gets thrown out is that good practice and that good engineering. What I fear for is that in the coming years, we’re going to have more of these issues that we often see in the news, where core pieces of infrastructure, because it’s now driven by technology are going to fail and fail badly, because of these things. I get the feeling we’ve been lucky.
There’s enough good stuff out there enough, good people that are holding it up. But as this continues to grow, that’s what I worry about. That’s my rant, how do we divide that divide, put more stuff in the leadership and make sure that the people are coming through understand those disciplines, and have the space to be able to innovate and lead like Raf was saying? Because yes, I have my gang of four book and my Kent Beck book and all those things, but they were the tools 20 years ago, how do we start to populate these new ideas.
Douglas Talbot: Great rant Craig, yeah. I’m fully supportive of this and I do think that so much now does rest on leadership that understands these concepts and can get its head around the way we should structure our organizations, lead our organizations, and bring all these things to life. And we’ve talked a lot in the agile community about bottom-up versus top-down. And I’ve become convinced that if we don’t get a revolution in the leadership knowledge that we’re never going to make the full shift we need. It’s almost becoming a generational game of the right people just coming through by dint of the wrong people falling off the top, and that’s a bit disturbing.
And I wish it could be a lot more intentional that we had leaders with growth mindset who are willing to go out there and learn how to do their job better and figure out what the modern world has to offer.
The rise of the B Corp – focusing on social good
So I think there is another more positive thing to say, however, Shane in terms of ethics which is maybe the rise of the B Corp and that might be worth saying a few words on if you’d like to go down that path, but I saw B Corp fraternity becoming much, much more strong in the last bunch of years in the UK. And over here in New Zealand, it’s got a bit of momentum and now when you starting an organization, a corporation in England, for instance, you get to select whether or not you want to make it for social good.
Douglas Talbot: And that’s a decision with the company’s office that you’re putting into your constitution and whether or not you would be assessed against that and what elements that would change about your obligations as an organization. And you’d have to actually fill in a report every year and file it on that basis. And there’s a change in the law for directors in the UK of large organizations that they must consider social good community good staff good, as well as shareholder good inside the organization. That’s now compulsory for directors of the FTSE 100. I think there’s an ethical move which has probably been instigated by some of the climate change discussions and other such things around the world over the last few years.
Douglas Talbot: I do think there is a positive thing happening there. I wish it was happening faster.
Shane Hastie: Anyone else like to comment on that.
My personal perspective there is yes absolutely, and we are starting to see that the organization that I work for, and Craig and I both work for now is a for-profit organization, but all of the shares are owned by a not-for-profit trust. And we see them doing good work with those profits that’s been for me personally quite gratifying to see. I know that C4Media the holding company of InfoQ also has a 1% pledge, and has a very strong social motive. We’re possibly seeing it from inside a small bubble, but I’m with you, I hope we’re seeing more of this.
Understanding the ethical implications of the tools we have available to us [58:33]
Raf Gemmail: I was going to loot this back to low code, no code, AutoML type space which is we talk about ethics. There’s also a movement going on where we’re empowering people to solve problems with off-the-shelf tools and it’s that whole with great power comes great responsibility thing, because those tools can often be using private data. They can often be vectors for attack into an organization. In one way, they’re helping us build the right thing. Sometimes, they may not be helping us build it right. And what I see at least in my space coming out of that is the need for responsible architecture around that, and that’s also mandated by regulation which means that I can see it impacting other organizations.
So, I’m thinking in the likes of GDPR, Chinese regulation, privacy regulation here in New Zealand, because there is a state level awareness of misuse of data. We’re also seeing the current situation, the horrific situation in Europe at the moment that cyber warfare is a major part of that. So, the decisions you make can impact an organization. They can impact a nation, the individuals in the nation. So, I’m seeing a need to be more intentional in the architecture of how we use those low code solutions and having an ethical outcome, i.e., we’re doing the right thing by people today. And we have regulations that are pushing us along the right way. Is everyone doing that?
Is everyone meeting the mandates of those regulations? Probably not yet, but it is again another step in the right direction, but I am quite concerned by the notion that there are many tools out there that make work and life easier. And they may have consequences which are counter ethical if we’re not responsible in how we use those tools.
Sandy Mamoli: Absolutely, I want to echo that with freedom comes responsibility. And that is both the tools and the frameworks we need to have in place around them in the form of a legal framework, in the form of governance, and rules and regulations. And the other thing I wanted to call out is that I think we need to be careful that we don’t just do leadership bashing that we go, “Oh, this is all leadership’s fault.” And while leadership of course has some fault in how things are not going great, I think everyone else needs to take responsibility for that too, because what I also see is that people are demanding freedom. People are demanding their right to just make decisions, their right to not have a hierarchy, to not have a leader, to break it to make all decisions themselves.
And I think that’s very naïve. The completely flat organization is naïve, because we all know what happens when there’s anarchy that it may remain flat for very long. It usually ends up in a dictatorship, but dictators that are not elected where there is no framework and regulations around who does lead. So, I think we need to be a bit careful to not just go, “Hey, abolish all the leaders and not go hierarchy is bad.” There is some hierarchy that is needed, and decision making power is great. Some hierarchy is needed, all those tools are absolutely great and empowering. At the same time, yes, we need to counter balance that too with regulations and rules about that.
Shane Hastie: Ben, can I ask you to chime in here, and this is your opportunity for a rant if you have one.
Trust and psychological safety have been severely eroded over the last two years [61:43]
Ben Linders: Well, my rant would be around trust, and I think that’s why we’ve taken the big hit in the last two years starting with COVID and now with the war. I think on the topic of trust, people are much more fearful on what they can say, or what they can do in organizations. And my negative self says we have been set back for at least 10 or 20 years on this topic. So, we’re going to need a long time to recover, and regain that level of trust again what we actually need for teams to work well. This trust is a foundation for psychological safety that you want to have in your teams, where people feel safe enough to speak up. And if they don’t feel safe because the whole world has become unreliable as people Europe see right now, you can still try to create that bubble of safety within your team.
That’s going to be, yeah, a big, big trouble thing and I think chance of realizing that it’s going to be very difficult. So, I think the key topic to work upon is to go back to this level of trust and create this openness in the safety of people for people to work together, and that’s going to take a long time. We’ll take the big hit in there.
Shane Hastie: So, how do we do it?
Ben Linders: Well, I think the key word is already in doing it and that’s where I would say like I know this is going to be difficult, but I want to stick to my values. I still believe in being transparent and being open when I work with people is the best way to do it. When I go in, I still start from trust by default. If I start working with somebody on whatever I do, whether that’s working for workshops I’m setting up, or working with a new partner to see what kind of training that we can deliver or connecting with somebody to do a Q and A for InfoQ, I start with trust by default. I start by being open about my motive, being open on what I would like to do.
Just bringing my whole self, the stuff that we’re working upon and seeing how that works out. And luckily with the people I work with, that still seems to work quite good. Trust by default and just trusting that your other party also wants to get the best result out of there seems to work well with the people I’m working with. And maybe that’s a lot on whom I’m working with, but I think the majority of the people still has adequate attention there. So, how do we do it? Stick to your values, even you know it has taken t. Just start from trust and start working with people from the bases of trust, and see how that works out. And most of the time, that works out well. That’s my experience at least.
Shane Hastie: Raf, you wanted to say something?
Evidence that some things are getting better [64:20]
Raf Gemmail: We’re seeing the world and the world is like going on a downward slope sometimes. And maybe we’ve had rants, but last year’s state of DevOps report, when you look at that, you see that they look at high-performing teams and they look at people who are feeling safe and communicating well, and releasing often and learning. And in there, it sounds horrible. I hate the language. They call them the elite group, but people who are performing at that elite level, which just means they’re performing well and they’re safe and they’re delivering, that had gone up. It dipped briefly in 2020, but it’s gone up again. And we’re seeing it go from like what I remember with single digits to something like 40%.
So, there is still always going to be a trend, and I think the trend is still going upwards. And we’re in a world where just about everyone I know is suffering from some sort of anxiety or who’s feeling uncomfortable, and we’re in these uncertain times, but we’re at this point in this curve. And I’m so optimistic the curve will continue as it has through history to improve for the betterment of humanity, I hope.
Ben Linders: Again, don’t give up.
Raf Gemmail: Exactly.
Shane Hastie: One last round, what is your message for our audience going forwards? Craig, can I start with you?
The trend is upwards [65:28]
Craig Smith: We’ve talked about all the things that are happening, and I love what Raf had said before. We go in these peaks and troughs. I think I just want to end by saying the reason that we can have a conversation like this and talk about these things is the base that we’re working from is a lot higher than it was a couple of years ago in relation to culture and methods, but we can’t take our eye off the ball the types of people who listen to this podcast, what really trying to say is that we need to work together as a community. We all need to think about how we can continue to make this better for everybody. Because every time we introduce something new, it moves things around and the world doesn’t stop.
I have this hope that we will continue to innovate and find great solutions to these problems. That’s my hope for this community.
Shane Hastie: Doug.
We live in a world of complexity and need a growth mindset to cope [66:10]
Douglas Talbot: I think the one message from me would be in this culture and methods space, everything is really, really complex and if we want to quote the Dave Snowden model complex inside Cynefin model. The only way we’re going to progress in it is by having a growth mindset and continuing to experiment, try, learn, and give each other feedback. And I think that that’s the fundamental here is if all of you out there can put on a growth mindset hat and be open to checking out the world around you, checking out what everyone else is doing, and actually challenge whether or not we’re going in the right direction on a regular basis, so we can pivot when we’ve gone off down some scary dead end, then we’re all going to keep moving forward.
The peaks and troughs will be going in the right direction, and so a call for growth mindset and learning.
Shane Hastie: Raf.
Work to improve your local context [66:59]
Raf Gemmail: I will reiterate and echo what everyone said as I’ve had with every other remark. I think I would recommend to everyone to look at their local context, yeah, understand your context and keep improving it, understand the challenges in your context the people challenges, the delivery challenges, the challenges that are there in these are unique times, but you can locally optimize, right? You can make things better where you are. You can learn from others and learn from this trends report, learn from the anecdotes that come up in InfoQ news and from elsewhere, and use that as a way to try and improve the environment that you can influence.
There’s only so much we can influence and if you can try and make a difference where you have that ability to make change, you will see as Doug said that trend or your place on that curve keep moving upwards.
Shane Hastie: Ben.
Make small positive changes constantly [67:46]
Ben Linders: Well, adding to that, if you’re looking for a way to change things in your organization, to change things in your team, make it small, look at the smaller step that you can do right now. And this is basically an agile approach to agility. If you want to change things in organization, look at what’s important right now and work on that, and don’t be afraid that you’re missing out on stuff because if it’s important, it will come back. So, don’t try to do everything, try to do as little as possible, but whatever you’re doing try to do that in the best way you can.
Shane Hastie: And Sandy, the last word.
We have the opportunity to rethink everything – try out new things [68:19]
Sandy Mamoli: In a way, nothing has changed we are still figuring out ways for how to collaborate better to create amazing things. In some other way, everything has changed and change in the recent past has been huge, not unprecedented, but huge. And in any change, there is opportunity. We have the opportunity to rethink everything, how we live, how we work, how we interact with each other, how we collaborate. And I think this is the age of experimentation. I want to encourage everyone to try out stuff and be open, and be open to trying out things. And some of them you like, some of them you won’t like, but now is the time to try things and to invent things, and make things better through trial and error.
Ben Linders: Love it.
Shane Hastie: That’s a wonderful ending point, make things better through trial and error. Folks, thank you very much. It’s been a pleasure to have the six of us together around a screen. One day, we’ll get together around the table again, we hope and I’ll put all of our contact details in the show notes. And just thanks so much and to our audience, thank you for listening to us.
QCon brings together the world’s most innovative senior software engineers across multiple domains to share their real-world implementation of emerging trends and practices.
Find practical inspiration (not product pitches) from software leaders deep in the trenches creating software, scaling architectures and fine-tuning their technical leadership
to help you make the right decisions. Save your spot now!
From this page you also have access to our recorded show notes. They all have clickable links that will take you directly to that part of the audio.
MMS • RSS
Posted on mongodb google news. Visit mongodb google news
MongoDB Inc. (NASDAQ:MDB) shares, rose in value on Wednesday, 03/30/22, with the stock price down by -1.30% to the previous day’s close as strong demand from buyers drove the stock to $430.22.
Actively observing the price movement in the last trading, the stock closed the session at $435.89, falling within a range of $423.00 and $443.28. The value of beta (5-year monthly) was 0.82. Referring to stock’s 52-week performance, its high was $590.00, and the low was $238.01. On the whole, MDB has fluctuated by 12.68% over the past month.
With the market capitalization of MongoDB Inc. currently standing at about $30.09 billion, investors are eagerly awaiting this quarter’s results, scheduled for Jun 01, 2022 – Jun 06, 2022. As a result, investors might want to see an improvement in the stock’s price before the company announces its earnings report. Analysts are projecting the company’s earnings per share (EPS) to be -$0.09, which is expected to increase to -$0.02 for fiscal year -$0.37 and then to about $0.15 by fiscal year 2024. Data indicates that the EPS growth is expected to be 37.30% in 2024, while the next year’s EPS growth is forecast to be 140.50%.
Analysts have estimated the company’s revenue for the quarter at $266.45 million, with a low estimate of $263.93 million and a high estimate of $276.38 million. Wall Street analysts also predicted that in 2024, the company’s y-o-y revenues would reach $1.18 billion, representing an increase of 35.20% from the revenues reported in the last year’s results.
Revisions could be a useful indicator to get insight on short-term price movement; so for the company, there were no upward and no downward review(s) in last seven days. We see that MDB’s technical picture suggests that short-term indicators denote the stock is a 50% Sell on average. However, medium term indicators have put the stock in the category of 50% Sell while long term indicators on average have been pointing out that it is a 50% Sell.
20 analyst(s) have assigned their ratings of the stock’s forecast evaluation on a scale of 1.00-5.00 to indicate a strong buy to a strong sell recommendation. The stock is rated as a Hold by 3 analyst(s), 15 recommend it as a Buy and 1 called the MDB stock Overweight. In the meantime, 1 analyst(s) believe the stock as Underweight and 0 think it is a Sell. Thus, investors eager to increase their holdings of the company’s stock will have an opportunity to do so as the average rating for the stock is Overweight.
The stock’s technical analysis shows that the PEG ratio is about 0, with the price of MDB currently trading nearly 20.29% and 13.05% away from the simple moving averages for 20 and 50 days respectively. The Relative Strength Index (RSI, 14) currently indicates a reading of 60.64, while the 7-day volatility ratio is showing 5.07% which for the 30-day chart, stands at 7.77%. Furthermore, MongoDB Inc. (MDB)’s beta value is 0.82, and its average true range (ATR) is 26.93.
A comparison of MongoDB Inc. (MDB) with its peers suggests the former has fared considerably weaker in the market. MDB showed an intraday change of -1.30% in last session, and over the past year, it grew by 60.87%%. In comparison, Progress Software Corporation (PRGS) has moved higher at 0.02% on the day and was up 4.88% over the past 12 months. On the other hand, the price of Pixelworks Inc. (PXLW) has fallen -5.31% on the day. The stock, however, is off -8.46% from where it was a year ago. Other than that, the overall performance of the S&P 500 during the last trading session shows that it lost -0.63%. Meanwhile, the Dow Jones Industrial Slipped by -0.19%.
Data on historical trading for MongoDB Inc. (NASDAQ:MDB) indicates that the trading volumes over the past 3 months, they’ve averaged 1.35 million. According to company’s latest data on outstanding shares, there are 67.00 million shares outstanding.
Nearly 2.70% of MongoDB Inc.’s shares belong to company insiders and institutional investors own 90.40% of the company’s shares. The stock has fallen by -18.73% since the beginning of the year, thereby showing the potential of a further growth. This could raise investors’ confidence to be optimistic about the MDB stock heading into the next quarter.
Article originally posted on mongodb google news. Visit mongodb google news
MMS • Ben Linders
Article originally posted on InfoQ. Visit InfoQ
Team-set salaries (TSS) can be scaled up by doing appraisals across teams where results are automatically calibrated. The scores indicate where conversations are needed. TSS encourages people to learn new skills and adapt.
Klaus Wuestefeld spoke about team-set salaries at Lean Agile Exchange 2021.
With TSS, appraisals are made by team peers using the zero-sum metaphor of “dividing up a pie”. It gives everyone a direct say in salary settings. TSS can be used for fair individual compensation in agile teams.
Wuestefeld explained how TSS can be scaled up to multiple teams:
Each appraisal in TSS has a certainty rating between zero and one, set by the appraiser, to indicate how well they know that colleague’s work.
When at least 2 or 3 people in each team are capable of appraising someone in a different team, even with a low certainty rating, then “cross-pollination” of appraisals is strong enough to have everyone in the same TSS round, sharing a single budget, and results are automatically “calibrated” across all teams.
When teams work in silos and know nothing about each other’s work, you have to do a separate TSS round for each team, Wuestefeld said. In that case, the budget (the size of the pie) for each team has to be decided by the company as it would using any other salary setting process.
TSS encourages people to learn new skills, new jobs and to adapt to our changing company’s needs, Wuestefeld explained:
We want back-end coders to learn front-end development. We want front-end coders to learn graphical design and vice-versa. We want everybody to learn about the business, about UX and about anything they feel might be important.
InfoQ interviewed Klaus Wuestefeld about company-wide team-set salaries.
InfoQ: What benefits can team-set salaries bring if you do them company-wide?
Wuestefeld: TSS does not require me to box people into rigid, limiting job descriptions such as “backend developer” and “UX designer” just so that I can compare them to the market.
True collaboration becomes more important than showing off to the boss. Power hoarding becomes less of a distraction. Compensation “calibration” meetings are no longer necessary because TSS results are naturally calibrated across all subteams. People become autonomous. Team boundaries become more fuzzy and less restrictive.
InfoQ: What about cheating? Can’t people simply give favourable appraisals to themselves or to their friends?
Klaus Wuestefeld: People don’t appraise themselves in TSS, only their colleagues. TSS results show me who made appraisals with the greatest “difference in opinion” when compared to the final result by the team. When two or more people disagree significantly with the team in favour of each other, I call them in for a chat.
Normally, they will have valid reasons to hold different opinions from the rest of the team. They will know things about their colleague’s work that nobody else knows and it is great to have their input. Fairness is achieved by being able to perfectly balance everybody’s point of view. But if they stutter and don’t have a good explanation, I can ask them not to appraise each other at all. This seldom happens because people know that cheating attempts become evident.
TSS results indicate what the most important conversations to be had are. I don’t need to have everybody talking to everybody else one-on-one. That’s a waste of time. I encourage team members to hold feedback sessions inviting only the people who are the outliers (positive and negative) in the “difference in opinion” metric regarding their work.
Because of network effects, as the company grows the impact of avoiding stress, performance review drudgery and insipid one-on-one meetings grow even faster.
MMS • Sergio De Simone
Article originally posted on InfoQ. Visit InfoQ
Based on the insights provided by Google’s Android App Vitals, Lyft Android team improved their Android app’s startup time by 21% and increased driver sessions by 5%.
What set off the Lyft team effort was discovering that their Android app was 15-20% slower than their competitors’ at launch. Launch time is a key factor to engage customers and the Lyft team saw there a clear opportunity to improve UX and engagement, which required to first convince their management of the importance of that.
As an app grows and the team grows with it, app excellence becomes more important than ever. Developers are often the first to recognize performance issues as they work closely on an app, but can find it difficult to raise awareness across an entire organization.
To get to the bottom of what was causing their slow startup, Lyft engineers resorted to using Android vitals.
Vitals gives developers access to data about the performance of their app, including app-not-responding errors, battery drainage, rendering, and app startup time.
The key metrics to observe for Lyft was time to full display, which measures the time taken to display the first fully-populated UI view, including any required networked content. In Lyft’s case, time to full display was the product of four different stages in their app launch pipeline: starting the app process, creating an Android activity to render the UI, requiring remote content, and finally showing the driver’s UI.
Thanks to these insights, the Lyft team took a number of steps to reduce the network overhead on their critical path. This required decomposing their backend services to remove some network calls, using asynchronous requests, and moving any blocking requests to background threads. Another area which brought improvement was using a cache to persist data across sessions.
Overall this allowed for reducing launch time by 21%, as already mentioned. Interestingly, achieving this result did not require a lot of manpower. In fact, it took a single developer just one month to achieve the goal. This was not accidental, rather the effect of an accurate initial investigation into what deserved an effort.
When starting your own app excellence initiative, it pays to first aim for small wins and build from there. Carefully pick actionable projects, which deliver significant results through an appropriate resource investment.
Android App Vitals are accessible from the Google Play Console.
MMS • RSS
Posted on mongodb google news. Visit mongodb google news
The results here are provided for general informational purposes from the CMLviz Trade Machine Stock Option Backtester as a convenience to the readers. The materials are not a substitute for obtaining professional advice from a qualified person, firm or corporation.
Article originally posted on mongodb google news. Visit mongodb google news