Transcript
Thanks so much for having me here. I'm really excited. Whenever you've got this, has any events going on? I love to join them. They've given me a lot of advice around strengthening my core skills. So I'm just pretty thrilled to be involved as Joe quite rightly said, my name is Jessica. I'm a developer advocate with LaunchDarkly and I came up with the idea of this talk in my first meeting with Kevin, we were chatting about the nature of events and projects and how The complexity scales with scope.
Okay. So I had this idea came up when we were talking about how project scale or going from like virtual events to IRA relevance. We made the offhand comment that not everything goes up by an order of magnitude of one every time. And that observation really neatly summed up a lot.
My experiences with projects and people, both professionally and personally, but also the research I've been doing around group organization and how that changes things. And the next 20 to 30 minutes or 25 minutes, I think we're going to talk about how to avoid the. Uh, that happened with siloed working and how to effectively distribute knowledge in a way that can help you gain visibility in your organization to just level up.
Let's do this. Let's kick things off with identifying the complexities that happen when that arise, when people organize, integrate. You'd be forgiven for thinking that collaboration is always going to be honest to our problems. You know, we often pair program. We say things like two heads are better than one.
And a problem shared is a problem halved. And it's understandable to think that bringing another person to the mix will stand to reduce our workload, to kind of ease our woes and get to a solution. Faster, but going beyond language, there are many instances where this logic is reinforced and it's not always the case.
If we're moving something heavy, more arms equals more power. Now our perception of how work gets shared more many has looks like this. We're used to thinking that more people getting involved makes things easier, but in reality, it often ends up looking a bit like this. These two graphs, both originate from a collection of essays from.
The mythical man month, a book from faint computer scientist, Frederick Brooks. It originally came out in 1975 and it spins subsequently updated twice and sort of once in 1982, once in 19, 19 25, but that's still a long time ago. And one is language and examples are in sore need of a refresh. Reflect the more inclusive spaces that we're trying to foster and build in sofa today, the core underlying messages, some of them really ring true.
I was in an event yesterday, which referenced this very book, the director of engineering, a takeaway giant delivery hero, talked about. The hero essay in this book, um, which discusses the perils of overstaffing and how this happened in the essay that we're referencing called the mythical MATTMAN it explains the unit of what they call a person month, which is highly, which is a highly fictitious amount of time, a unit of progress.
Rather that group of people can make. Relative to their quantity and the subsequent amount of time a task takes them. So the idea is that the number of people and the amount of time required to get something done or get something working can be interchangeable. As commodities and that's where the idea of the person month comes from.
But this is only true. When a task itself can be partitioned amongst many people with no communication between them about that task software development is one of those tasks that falls in between the two categories of it can be partitioned, but also re we need handoff between each stage. Break things down into smaller user stories.
We can break things down into features. That is what we do every day, but we do need communication, even if it's just in the baby. Format of get, or a version control crisis. We need communication between each unit of work and in these situations, the best possible outcome doesn't come close to an even trade off of people versus salvers.
And there are a couple of schools of thought around where the work lies, but it's widely accepted. The intercommunication is where the majority of work is concentrated. And if each part of the task you're working on east to be coordinated separately between certain people, the effort required to complete that section of work increases at a rate of N to the power of.
Minus one over T that sounds a bit difficult to conceptualize. It essentially means that three people will require three times as much interaction as two people to get the same amount of work done. This graph here is kind of what I'm talking about. You kind of see this really sharp increase point when it hits about three or four people.
And things only get compounded when we bring department wide meetings into the mix. And the result of this leads to the effort of communication, almost counteracting, the division of labor. It can cause communications of really difficult and it led to the discovery or the sort of the, the creation of this law called Brooks law, which is the.
People power too late. Software projects only stands to make them later, but what does this mean? And this isn't an argument against collaboration working together is integral to getting things done at scale. What I'm trying to do is make sure that we're aware of the pitfalls that happen in these scenarios.
Not dissuade communication as a whole communication is wonderful. We really need to keep talking, but we need to make sure that we're talking in a way that supports our overall goals. Of what we're trying to get done too much communication and people feel included, but things can sometimes slow to a halt as we saw with base these very exciting grass, but also too little, at least for another set of problems, people feel out of touch with the decisions being made.
They lose motivation, they become disengaged. I mean, does anyone have any. Does this resonate with you? Have you ever kind of felt a little bit like out of the leap at work, like things are getting decided without your input at best, we ended up working in silos, unable to collaborate outside of our immediate team, which might not sound like the worst thing, but.
When that problem gets compounded, it can lead to attrition. It can lead to people being disengaged with their responsibilities and the outcomes of their work. Now, all in all, this is not great at a individual or a team level. So how can we get the levels of communication just right. One of the ways to do this is to create a bit of a rhythm and a cadence around the way that we've work, establishing a sense of predictability.
Kangaroo trust and help people engage in a bit of taste that communication where they feel communicated with, but they are able to act under known and tested assumptions that can contribute towards group success. And we're going to look at a couple of frameworks and a little bit of, um, advice that you can use to model this in your interactions.
And the next time that you lead a new project or initiative, hopefully you can put this into practice now requirement's we encountered this. Okay. These are usually discussed at a product level rather than a project level, but we can actually use the idea of a requirement as almost like a framework for understanding what's needed to me all goals.
Yeah. Every requirement at school is a condition or capability needed to solve a problem or achieve an objective and requirements. Engineering is a term that broke onto the scene around 1997. I do have a love for the nineties. This talk will quickly speed up into the 2020s. And it evolved through a series of conferences and discussions, and then developed into a standard series of practices.
The drawing up of requirements has now become a fundamental part of most life cycles and is referenced heavily all across the work that we do. But requirements engineering is a process of eliciting stakeholder needs. And desires and developing them into agreed upon set of detailed requirements that can serve as a basis for all subsequent development activities.
Another purpose of requirements engineering is to make sure that what's being stated is clear, complete, and that the solution proposed is correct reasonable and effective. Um, that all sounds great though. Sounds really ideal. Um, but in. Reality kind of, how does this come to life and calculates about four steps here?
We've got elicitation. That's all about understanding the needs of what, what we need to get done, understanding the needs of our stakeholders. If we're being tasked with a project, figuring out what are the core goals, what do we want our final solution to do? What sort of requirements do you want it to meet?
Next documentation. So clearly capturing those and documented format that's referenceable and has a lifecycle. And we're going to visit that point later. Clarity, completion and accuracy are really key here. Documentation. We usually think of it as a one way process, but documentation really ensures that we're engaging in active listening and that we've documented that we've understood the task correctly.
Validation. That's the clear, continuous communication process that helps us validate our thinking. And then lastly management, the final state that involves managing any changes that may arise along the way. I'm doing this in a sort of transparent way. Now this is, these are all super broad concepts, but let's kind of drill down a little bit into what they mean when we put them into practice.
So elicitation that may be kind of getting a brief sounds pretty simple, but this first stage is essential for being able to start things off in a successful manner. And then once you've gotten your brief and clearly defined the requirements what's required, what does success look like? And really mapped things out in terms of the assumptions that we're making for the task.
We want to kick off with an. I hate the head, but one, maybe one, one meeting, one initial meeting to get everyone on the same page. And this is where you can really, your project brief really clearly with your team, define all of the requirements or make sure that your defined requirements are stated and chat.
And yeah, I outline the work that we're intending to do going forward now, starting things off with a kickoff meeting that includes a bit of a user manual of how you want to work with each other is a great way to make sure that people are able to understand the processes that you're going to take going forward.
So the goal here is to prevent future meetings, kick things off with a definition of the requirements, also how you expect to work going forward. And then lastly, Talk about what you want to achieve and clearly estate, the assumptions that you're making. Who are you making this product for? Who is this project aimed at, along with the challenges that you've anticipated, then ask for feedback.
This is going to make sure that anything that you bring up at this stage is open for interrogation and a really honest, communicative way when I was putting this talk together. I wanted to reach out to someone that I knew had a lot of project management experience and that's Louise here. Please feel free to follow her on Twitter.
She's a great resource for lots of project management, tips and tricks, but she mentioned that the management of focusing on engaging people early is a really great way to start to establish trust. She said here that. TIG and have an understanding of the business case and client requirements. The only way to really foster empathy is by practicing it.
So that's why it's a great shout to get your meetings in early and then start to collaboratively, define the way that you want to work going forward.
How do you do this? I know that a lot of this advice is very applicable to many scenarios. As a sort of concrete example, I work on one of the ERDs at my workplace. And the way that I like to kick off every year is by holding a quick meeting with the other ERG leads and the people responsible for managing the program.
And they just sort of archeology. Although this sounds like it contradicts the advice and the very first part of this talk. Great part of this is that it allows every idea that you bring up to the open to interrogation. You get to be truly collaborative from the get-go and take on board everyone's feedback.
Then you have a starting point for all of your communications on slack.
Documentation is part of communication as well. We transparently relay that we've understood something accurately and it's one of the most important parts of knowledge distribution. Now, this book written by my colleague, Heidi would house amongst other collaborators. It goes into some brilliant practices and processes around technical documentation, and I highly recommend that you pick it up as a guide to documenting with good practice.
Use tools that your team is used to using. If everyone uses slack stares suck. Now of course you can build the business case for a better tool if you need that, but make sure that you're using something that people are familiar with. That's an agenda point that you can add your initial kickoff meeting.
How does everyone want to work? And what tools are they want to work with? Making sure that you're being collaborative and the tools that you use is also a really good way to keep people engaged. I think it was a study done recently talking about how people having autonomy over the tools that they use leads to overall project engagement as if the people that you're working with get to choose their tools and you get to work with what they find the most easy to use.
That's how you're going to hopefully keep your documentation fresh in their minds and heavily referenced, which is of course what it's there for. It's there to be read. Secondly, give your information a lifecycle. It will not say relevant forever and make sure it's updated. And it has a lifespan. So people know how often to try to check the changes and how much they can trust it.
So by standardizing both the tools and the patterns by which we operate, we understand, we grow to understand what to expect from it. Uh, he can see a typical pattern for communication. Uh, this road bus pattern invites collaboration in a really predictable and controlled way, and it tries to minimize context switching, if done, if done in the right way.
The key here is to also minimize cognitive load. Now people use what they're used to using. They won't have to think about how many people should I talk in this post? Is this the right way to do this? Do people tend to use Atlassian? Do these templates is merely the best tool for this. If you are really intentional and really specific about how you start to document the information for your projects, then this layer of thinking won't even need to happen.
And people can only do what's expected of them. And by creating a defined process, we instill a thing that we can trust that we can trust and work to improve. And there's practical terms when you're thinking about how this might work with say incident response, look at slack integrations. Look at teams integrations, look at what you can build on top of what you already have.
Now step three, validate. Now this is where you understand how many of your assumptions are correct. And how much of the information you've documented is useful. Now this is a state that you want to really lean on quite heavily. This is a part of the process that you can start to dig deeper into set barriers.
You can start to understand. Where are people asking the most questions in your brief? Whereas the most misunderstanding as a example here, I was chatting to someone a while ago about learning TypeScript. And I started to get some feedback around which projects I should start to include in my brief. And in my outline, he see the building small sample sites as a first project is a really good option and that's quite.
Good bit of advice, but I might have assumed otherwise might've assumed that I should focus on only exercise based learning. So validating your approach here is just a really useful way to make sure that you're staying on track. It's a great way to ensure honest communication and to make sure that you are course correcting as you go.
I love this point here by Jim Roan. If someone's going down the wrong way road, they don't need motivation to speed up. What they need is education's turn around and that might be what you need. Now management is a kind of final point and that's a very, very broad term, but essentially what we're going to talk about is what happens when things go wrong.
Now, dynamic complexity is something that comes into our projects quite a lot. The time when we're dealing with technology. Engineers, we're hedging our own ability to understand new knowledge. We're hedging our own selves to be able to figure out something new most of the time, but we're joining a new project and software gets complicated really fast.
Sometimes you can't know what you don't know. And that sort of idea of an area of complexity that has the ability to change is called dynamic complexity. Now, going back to some advice from Louise, she kind of talked about how planning for the unknown. It's something that you inevitably have to do when you encounter a project, you don't know what's going to go wrong.
And sometimes the best option is to make sure that you've set up these really clear communication cadences, those weekly check-ins or that daily standup routines on a project. Even if it's just quite a small project that you've been tasked with. So you can share early what's going wrong and what you suspect might be happening and how that's going to impact the overall schedule.
It was a do this. You've got to create a bit of a blameless culture. Um, I blame us culture. Doesn't focus on where someone went wrong. It focuses on a system or a process that failed and it can really increase our tolerance to bad news.
One of the things that are blamed was culture leads. Here's a bit of psychological safety, um, and that's where people can show up to projects. They can show up without fear of consequences, everyone on your team, your project group, they need to feel empowered to speak up. If things are moving too fast, if they're concerned about the direction that you're going in, or if things are at risk of going wrong.
And the only way you can do that is by keeping on talking about things that are both. I'm bad. And then establishing that both of those things are okay to voice. And one of the ways of doing this is to focus on what or how. Don't ask about why, because it's easy for people to become defensive of the why.
Obviously we need to question maters and keep things going. But sometimes in difficult environments, we need to really raise the baseline when it comes to, uh, psychological safety. And we might be coming from a place that's psychologically quite unsafe, and we might be using new project as a way to refresh our way of working and a good way to start doing that is to focus on how, how did an outage happen?
How did it happen?
This how helps us to make curiosity and learning a priority. It helps us to reward great questions and foster inquisitiveness in all ways of work in our teams. And lastly, Making sure that we have time to play and experiment is a really great way of making sure that we're not overexerting ourselves and making every point of our project.
Stressful. Maybe we have one or two requirements are soft requirements or less important than the others, less critical. And I'm kind of like nice to haves. That's potentially our area where we can add our project flare or have a bit of individualism or. Exactly ownership over a product a bit, essentially.
You want to make sure that your knowledge management is a moving objects. You wanna make sure that you're distributing what you learn, you're effectively using it. And you're capturing the outcomes of implementing that knowledge. Here's a little bit of a TLDR, and I'd love to speak to you about what you're working on.
If you're working on a new project or new initiative at work. Please hit me up in the DMS. And I'd love to work with you on how you can work to include a bit of requirements engineering in your day-to-day working to make sure that what you create is a bit of a success. So thank you so much. I really appreciate you listening to me, asking questions, keeping it dynamic, and I'd love to chat.