Framing the Relationship Problem 0:00You might be surprised that this video is one of the topics that I'm covering. Honestly, I'm a little surprised because it's not a topic that is often covered, but it is so important that it's worth trying even though I don't know exactly how it's going to go. I have often, often, seen problematic difficult relationships between the engineering side of the organization and the rest of the organization end up completely demoralizing developers and completely diminishing theirrest of the organization end up completely demoralizing developers and completely diminishing their productivity. And this problem is like a cancer, all the best leadership you can possibly do inside of your engineering team, all the best organizations and structures, none of it matters if you can't fix this core problem. And also, by the way, in this episode, I'm saying engineering a lot in place of development because more often than not, all other engineering considerations like IT andplace of development because more often than not, all other engineering considerations like IT and UAT or testing are lumped together with development on one side of these conflicts. Now, there are some ways that issues between engineering and the rest of the organization present pretty consistently across different types of organizations, but there are also some groupings where there are certain types of issues that happen in this context that are specific Organization Types Overview 1:15groupings where there are certain types of issues that happen in this context that are specific to a particular type of organization. And this is not a perfect grouping, it's really just based on my personal experience. But in my experience, there's about five groups that I think have their own unique ways of experiencing these sorts of problems. And those five groups are non-profits, marketing agencies, development agencies, tech startups, and then basically everybody else.marketing agencies, development agencies, tech startups, and then basically everybody else. And we will start with the issues that are consistent across all organizations, and then we'll talk about some unique issues about each specifically. But first, I've found that many of the more universal dynamics we're going to talk about aren't present at all non-profits. And that's not to say that non-profits don't have issues or that none of them have these universal issues, but just that working as a Non-Profit Challenges 2:00have issues or that none of them have these universal issues, but just that working as a programmer on a non-profit often presents a unique set of challenges. And I just want to give you two small examples. With smaller non-profits, you're super commonly the super hero who does absolutely everything, from front end to back end to mobile work to fixing the printers. If it's tech- related, we expect you to fix it. And this very commonly leads to burnout or devsrelated, we expect you to fix it. And this very commonly leads to burnout or devs leaving because they don't get paid enough for this. And sometimes this is all just because non- profits have sort of an all hands on deck mentality. Sometimes it's because they have unrealistic expectations from the very beginning, but sometimes that first programmer that they hired was a jack of all trades, who was a little bit a programmer and a little bit a lot of other things, andwas a jack of all trades, who was a little bit a programmer and a little bit a lot of other things, and that was fine, but that person left. And then they said, "Well, we need to hire another programmer." And so they hired for a normal developer expecting to get another jack of all trades and just didn't know how big their expectations were. With larger non-profits, they're more likely to be corporate, so they could have more overlaps with some examples we'll talk about later.to be corporate, so they could have more overlaps with some examples we'll talk about later. But I also found that a lot of medium to large-sized non-profits are the most common, the most likely to use guilt and pressure to expect unrealistic things from you. They often have this hook that it's all about mission, and they try to use that hook to get you to work for, you know, beyond what is actually reasonable. Kind of now that I think about it , it's kind of like a lot of toxic startups, basically. And then there's some non-profits that, it's kind of like a lot of toxic startups, basically. And then there's some non-profits that are just the absolute dream, right? No pressure to deliver on unrealistic expectations, and I towards your long-term growth and overall peace and health. And I've seen this often at public institutions, like colleges. Unfortunately, I have worked with non-profits. I've worked in non-profits, but I am not the most experienced person in terms of thinking about non-profitnon-profits, but I am not the most experienced person in terms of thinking about non-profit leadership, about how to solve these problems and issues there, or even how to find those ideal kind of unicorn-type non-profits. But I would say that if you are in technical leadership in a non-profit, be sure to look at what is reasonable anywhere, not just at your job, but anywhere, to ask a developer to do, and try to shield your team from unrealistic oxide Universal Engineering Conflicts 4:05anywhere, to ask a developer to do, and try to shield your team from unrealistic oxide expectations outside of that, or pressures to do more than what is actually healthy for them. Okay, so we covered non-profits. Let's go back to the shared issues I see across different types of companies. I think there are three big categories of issue that I commonly see. First, that the things that matter to engineering aren't prioritized at an organizational level, and thisthat the things that matter to engineering aren't prioritized at an organizational level, and this might be things like taking time off from feature development to address technical debt. It might be about minimizing meetings to focus on flow state or whatever else. The engineering team is asking for things and they're not given importance. The second is that engineering is committed to timelines, timetables, deliverables that they didn't actually have a say in planning,timelines, timetables, deliverables that they didn't actually have a say in planning, and little chance to give any feedback on it once that actually happens. And third is when the business is not getting the pace of feature delivery that they want from engineering, they push for more and more micromanagement, focusing on quantity of output over quality. And I don't have all the answers for all of these, but I can tell you that there are two common sources of these issues. The first source is that members of the engineeringthere are two common sources of these issues. The first source is that members of the engineering team are seen as a bunch of neckbeard nerds who don't understand what's important, and don't care about working on the things that matter to users or the company, they just want to work on shiny nerd passions, basically. I wish I could say this was an entirely unfounded caricature, but we all know it's not. This actually does happen. The problem is whether it's coming from other folks'all know it's not. This actually does happen. The problem is whether it's coming from other folks' real experience in the past with other developers, or the behavior or your developers, or it's just a completely unfounded bias and caricature. This idea spreads, and more and more, the people who rely on developers to build things, they start seeing them as a group of stubborn, selfish, petul ant children who need to be micromanaged in order to get them to do anything useful. And thenant children who need to be micromanaged in order to get them to do anything useful. And then the number two source is, development is seen as more of a trade, like building a shed or installing a toilet, than a creative discipline. It's seen as a set of tasks that can be done over and over again, the full scope of which you probably learned in your initial training. So you learned how to install a toilet, great, now you know how to install any toilet, and you knowlearned how to install a toilet, great, now you know how to install any toilet, and you know exactly what it's going to take and how long it's going to take. There are valuable and honorable aspects of being compared to the trades, 100%, but it does start to really break down when that leads to others assuming things about the work of development, and more importantly, the planning of development that aren't actually true in our contexts. So make sure you check out my video Fixing Misalignment Through Leadership 6:38planning of development that aren't actually true in our contexts. So make sure you check out my video later about estimation, which I think will speak to this a little bit more. Okay, so we have identified what might be some of the core issues between your engineering team and the rest of the company, what does it look like for us to solve them? If they can be solved at your organization, which is not always the case, they're usually going to have to be solved by theorganization, which is not always the case, they're usually going to have to be solved by the engineering leadership team, which I hope is you. So if development, for example, is misunderstood as a rope task, you can take on the responsibility of educating the rest of the leadership or the rest of the company on what development really looks like, you know, bring them along to a planning session with your development team or help them solve a particularly complexalong to a planning session with your development team or help them solve a particularly complex challenge together and help them see both by the examples you're showing, then also your explicit communication, how custom application development is effectively the creation of something new that has never existed before. This is an artistic, a magical kind of process, and we want them to see the art and the magic and what we're doing. And if your team isn't doing art and magic,them to see the art and the magic and what we're doing. And if your team isn't doing art and magic, then the issue may be less about their misunderstanding of how you work and more about maybe that's just what development your company looks like. And I don't mean to be disrespectful, but if you're developers, you know, this is especially true if they're offshore, can't complete a task unless it's been specked out in every single detail, then this problem you're having might actually just be abeen specked out in every single detail, then this problem you're having might actually just be a part of the deal with the, you know, you made with the devil by hiring butts and seats programmers, probably for the cheapest rate you can possibly get. And this same solution applies if you have the other problem, you know, and your team are seen as neckbeards who want to spend their time adding final before all their classes instead of actually doing something productive. If you got aadding final before all their classes instead of actually doing something productive. If you got a team of bike shedding neckbeards or a gaggle of useless juniors, the rest of the company may see them as in need of micromanaging because maybe they are actually in need of micromanaging. And at this point, it's clear that you want that not to be the case. So what does it look like for you to engage your developers in the mission of the organization? What does it look like to takeyou to engage your developers in the mission of the organization? What does it look like to take them through the definition of some new task in a way that helps them understand their connection to serving real human beings, not just code, nurturing, or is that even possible given who you have currently working for you? If not, there are potentially some hard questions for you to be asking in the future. But if you have the well rounded, empathetic, capable developers we'vebe asking in the future. But if you have the well rounded, empathetic, capable developers we've been talking about throughout the entirety of this course, then your communication has to make that clear to the rest of the organization. It's not a matter of fixing them. It's a matter of just fixing everybody else's understanding about them. And one way you can do that is you can acknowledge developers overall tendency towards things like shiny object syndrome. So you can point toacknowledge developers overall tendency towards things like shiny object syndrome. So you can point to things that you've done to try and battle that kind of stuff. But then you use that acknowledgement of criticism to then turn around and say, but these other aspects of what we need are legitimate. And this might be about approval to pay down technical debt or getting budget for attending conferences or whatever else. But now is the time to show the value of thosefor attending conferences or whatever else. But now is the time to show the value of those things that you're asking for in a way that makes sense to the non engineering folks. Talk about the potential costs of the company if technical debt goes unpaid long enough or share the ups ides of devs on going growth as developers, speak their language, but in doing so advocate for your team. So let's get to talking about the issues specific to particular types of Issues by Organization Type 9:56your team. So let's get to talking about the issues specific to particular types of organizations. First off is marketing agencies. And there's only really one main issue that I 've noticed that are relatively consistent and relatively unique to marketing agencies. And that's these firms are most commonly run by people with no development background. If anything, they 're most likely designers, but that's not even always the case, but they're very frequently're most likely designers, but that's not even always the case, but they're very frequently people who've done some form of consulting or agency work. So they understand that piece, but they 're not developers. So they don't understand that piece. And they very, very often think of development as purely a end stage implementation detail, you know, like, once we've finished the real creative work, the artistry, I guess we have to hire someone who can translatefinished the real creative work, the artistry, I guess we have to hire someone who can translate our vision into dirty, gritty reality, right? And so while the source of this one is different, it's about the leadership being designers, the solution is still the same. Look at your team. Are you doing creative work? If so, make it clear to leadership, tell the story to them about how what you're doing is just as creative. And if not, then either change it, you know, change the way thatyou're doing is just as creative. And if not, then either change it, you know, change the way that you're approaching your work and try to get people to have more of a creative, empathetic understanding. Or if you can't do that, or you don't want to do that, then accept your fate that you will always be seen as the implementers. And that's just your lot in life at this company, at least, you know. Okay, moving on to development agencies. I run a development agency. So I'myou know. Okay, moving on to development agencies. I run a development agency. So I'm very likely blind to what goes wrong here, especially in my own organization. But if I had to guess and think about my experiences running my company, I would guess that the worst tendency in agencies like mine is for the salespeople to make promises that the devs have to keep. And I 'm really scared that one day this is going to be me. I'm on business development calls'm really scared that one day this is going to be me. I'm on business development calls all the time, making promises about what we can do in a general sense of what it's going to cost or how long it's going to take. And I'm just like afraid that one day I'm going to learn that Tighten devs sit around and grumble and gnash their teeth about Matt's unrealistic expectations. He sets with clients. So what does it look like to fix this? Well, make sure that your sales folkssets with clients. So what does it look like to fix this? Well, make sure that your sales folks are in tune with the developers as much as possible listening and asking them about how are these projects going. Make sure to do retrospectives after projects to say what was that like for you ? What could we have done better to set you up for more success? And also just make sure that they know that even if it's not a specific ask, they can speak up if they're ever concerned aboutknow that even if it's not a specific ask, they can speak up if they're ever concerned about being over committed and make sure that they know that if they do speak up, they're going to be hard . And second, maybe start bringing developers who still code daily along on your sales calls, you know, get their insight into the proposals you're making, get their eyes on this work before it's signed to see if they can start giving you kind of a fresh understanding of,before it's signed to see if they can start giving you kind of a fresh understanding of, you know, what the situation is. There is so much wrong with so many tech startups. I can't even begin to describe where the most common problems arise. But when it comes to the relationship between the engineering department and the tech startup and the rest of the startup, I would say the most common issues stem from the way that founders are often drawn to the novel. So you thinkmost common issues stem from the way that founders are often drawn to the novel. So you think developers have shiny object syndrome, try talking to startup founders. And this may come across in constant changes in scope or poor definition of features, or it might be in inappropriate requirements to use whatever the latest hot technology is even when it's not a good fit throw AI in everything, right? Solving this issue requires a bit of leading up because I assume that you'reeverything, right? Solving this issue requires a bit of leading up because I assume that you're not the founder. I mean, if you are great, you know, do better if you have this problem. But assuming you're leading up startup founders can be caricatured as thinking they know everything and not willing to learn, but often they're actually open to their trusted leadership, having a hard conversation about how they need to stop what I call the swoop and poop where they just show up andconversation about how they need to stop what I call the swoop and poop where they just show up and completely change everything in favor of means of communication and tasking that is more likely to produce the output they want from their devs. Again, you want to put it in their language. A lot of this video has less to do with how the teams interact with each other and more to do with how the leaders of the teams interact with each other and also how they do or don't effectivelyhow the leaders of the teams interact with each other and also how they do or don't effectively represent the interests and concerns of their teams. I've said this in previous videos, but if you don't have at the head of your engineering department, a technical leader with a large amount of power, you're going to end up with these problems or others because it's unreasonable to expect the non-technical leaderships of your organization to understand the needs and constraintsto expect the non-technical leaderships of your organization to understand the needs and constraints and concerns and fears and desires of the engineering team, which means you either need A, an incredible organization with just unbelievable cross disciplinary communication or B, you need a technical leader who gets why the engineer's priorities matter and can speak to them across sil os. In the end, this concept of the development team's relationship with the rest of the organizationIn the end, this concept of the development team's relationship with the rest of the organization really just comes down to how well the engineering leadership team interfaces between their team members, desires and concerns and those of the rest of the organization. It's going to mean critical conversations, intentional and often difficult interactions and knowing when to draw line both with the rest of your organization and with your team.line both with the rest of your organization and with your team.
