The Engineers Are TOO Productive! What Do We Do?!

Transcript is auto-generated and may contain errors.

Hey folks, we're going to go to the Experience Dev subreddit this morning. Um, this one it's kind of interesting because I think it feels almost backwards um from what I've been I think I've been experiencing what I've been hearing, but this person was saying that they're they're an engineering manager at a larger tech company. They don't specify which one. And they were asking how to how to cope with how to navigate um the scenario where there's so much more developer throughput versus the like product or design or sort of like upfront throughput meaning like I guess developers have been able to leverage AI to scale what they're doing significantly. definitely faster than what's feeding into, you know, what needs to be built. And um I I had to like read through it twice and then and then check a comment uh because I was like, hold on, I must I must be reading this wrong.

Like this must be uh the inverse of what I'm I'm reading, right? And I guess not. Um and so all these wipers are funny. Um, so I thought you know like from my own experience this has been so backwards because uh essentially like yes have you know developers been able to use AI to to do more? Sure. Like I think if you put AI in front of someone and they get familiar with using it, they can probably like most likely use it to scale up the specific things they're doing. And so when I think about software development, and I've talked about this before, but I kind of think about it like a pipeline. And um in a pipeline, you have different stages. You'll have things that can go in, you know, uh in parallel. You'll have things that have to follow sequentially. You'll have bottlenecks in the pipeline based on throughput of different things.

Um and so when I think about that, the part that like to me seems like I've observed the most sort of uh increase is is the beginning of the pipeline, right? And so like some examples of this are um okay you have you can aim AI at anything you want and say hey like I want you to uh you know go look for security vulnerabilities and then it will go make you know 100 GitHub issues or I want you to go like you know review the UI and look for things that we could improve and make GitHub issues for that and then it goes off and makes a 100 and then you're like cool like that was a lot of my job So like what if I can just you know put that on a schedule or automate that.

And so now you have these things up front sort of in this pipeline for software development that are just creating tons and tons of like AI uh requirements specs like bugs feature asks and it's like it's pretty unbounded and that's like that's been my experience uh primarily right so uh it also means that like beyond just that it's like if you of an idea. Like don't get me wrong, if you have an idea and you're familiar with software development and you are, you know, capable of using AI, then you can take an AI, sorry, an idea and go to implementation pretty darn quick, right? And in some cases, like depending on the scale and scope of what you're talking about, maybe to, you know, to final version in not too long. And like that's that's a pretty tremendous advancement. And uh but like what's what's easier than going from idea to like full-on implementation?

Well, it's from going from idea to spec. So, it's almost like anyone who's had an idea before can just go from idea to spec like within minutes, right? So, the bar is extremely low to go from idea to spec. Um, now again, don't please don't misinterpret what I'm saying. I'm not I'm not suggesting that means good spec or spec that everyone agrees on or spec that makes sense for us to go implement. I just literally mean you can go from having an idea to having AI blast out a huge markdown file even with pictures in like a matter of minutes. So, you know, going from idea to spec is extremely easy. Again, not not setting the bar for how good the spec is, just saying that it's very easy to do. So, again, like my experience has been quite the opposite of what this person's saying.

Um it ends up meaning that yeah like developers in theory can have more throughput but because so much more is coming uh from the start of this pipeline and like kind of funneling through that once again like developers end up being the bottleneck not the stuff up front. So this person's ask is when it is the other way what what do you do? Um, and so I I think that this is going to depend largely on maybe the industry you're in, what your teams are doing, the domain you're in. Like if you are a I would feel a little bit more I don't know like cautious about this if you were uh a software development team working in a you know not primarily software company, right? I realize that might sound kind of weird. Maybe some people are very used to this.

You know some people work at companies where the primary product is some something maybe some physical product or something and also it happens to need software right uh or I don't know it's like the the software part is just a piece of what is being delivered and uh customers are purchasing whereas other companies like even the part of Microsoft that I work in like everything is software I I realize Microsoft yes has physical products like like Xbox or other things like that, but um where I work it's it's just purely software. And so that's all we think about is software software software. So, um, the reason for my hesitation on like if you're a non not primarily a software team is like what I really wouldn't want people to have is like, you know, an overflow of like let's just go build stuff that, you know, is not going to sort of mesh well or jive well with whatever other parts of the business are going on.

Right? Could you imagine like just hypothetically, right? So say there's some there's some physical product that's being shipped and like the software is just like some some part of that. Not to not to minimize like the value of the software that would be shipped, but it's a it's a part of the of the thing that's being shipped. And could you imagine if like the software team just went off and like you know completely built all this other stuff that like the marketing team isn't or and sales team is never planning on using. It's not cohesive with what their like actual target audience wants because no one's done the market research on it. Um like it's you can't just like build stuff and then expect that that's like going to translate into um like usable stuff or valuable stuff. Again, please don't misinterpret what I'm saying. I'm not saying that developers can never do that.

uh what I am saying is that just because you can do it doesn't mean that it will be good right and then if you if you agree with that statement and then you say okay well now let's go do a add a bunch of people that can do that I mean you're potentially just going to be adding a lot of bloat and not actually adding a lot of value so in a nonsoftwarebased company I would be a lot more hesitant to say, well, why not just get, you know, developers talking about things and then like starting to ship ideas like yes, I think that would be part of it, but I think you'd want to be a little bit more cautious. Whereas on software teams, when the whole thing you're doing is software, yes, you still have this risk. Again, don't get me wrong, but like the product itself is often software.

Uh to take it one step further, like I work on a platform team at Microsoft and so like you know if just to make up an example, if we if I could snap my fingers and instantly ship 100 times the number of features that we have in the product surface area right now, it wouldn't change anything for for our uh our platform or our users like in terms of like how they consume it. like we would have to go enable those things and and do it. It's not like all of a sudden, you know, people that use our platform would be, you know, overwhelmed with the number of features. Like that's just not going to happen. But if you have users that have to like, you know, click through a user interface or they're like physically using the product, like actively using the product, like that's where stuff could get incredibly overwhelming uh and feel bloated.

So, um, to be a little bit more pointed here, my suggestion, uh, or one of them would be like think about the space that you're in, like how I was just trying to give you some different ranges of this and then like how can you take developers who are getting a lot more throughput and how can you try aiming that at some things that you know could potentially be uh, more upstream to their work already. Okay. So, one to me something that feels maybe more safe is like okay like um how do we start looking at quality improvements, right? How do we start looking at um you know uh amount of efficiency that we have in our our builds or deployments and things like that. Um, if you have a live service, right, and uh the the risk of an incident is there, like can you start looking at things like how do we mitigate faster?

Can you start hardening security, right? Like are there things that you can put developers aimed at that are like, let's uncover some some things that could be worked on, right? So that's looking more upstream and if we were to work on them is not necessarily going to bloat the deliverable that we're giving to the end user. I would say that is like certainly an opportunity um that feels to me safer. And I'm going to expand on this because I I hate that it sounds like I'm saying, oh, developers can't ever, you know, decide what goes into into products or anything like that. That feels very bad. That's not my intention. I'm just trying to approach this in a way that I would feel like I'm not just creating work for the sake of creating work, I guess, is my my point. Um, I think there's a lot of efficiency gains that can be looked at.

So, you know, if you have I'm talking about this in such a general sense, like I don't know what your product or service is, but uh I'm sure there's operational costs or costs to be able to to put things together. So, could you start having developers collect data on that? Look at where there are inefficiencies. Um and you know those optimizations could literally come from um wasting less time on things uh from agility in terms of you know not uh any longunning process or anything that's going to take a long time. Can it be done more incrementally? Um if you have to roll out changes can you roll them back faster? That kind of thing. Um and then o yeah so overall becoming more lean or more agile in terms of your uh ability to ship software or or mitigate issues.

Um, I think from that like again I don't know what the specific team layout and stuff is or what your your company would look like but if you have the opportunity where you know you just have so much throughput from developers I would be looking at ways to find developers like partnering up with with product managers um as much as possible. And so what I mean by that is like when I when I think about roles that people have on a team like I say this as someone who has worked in startups for you know many years. I've been in Microsoft now for a while and it's catching up on my time in in startups but the first you know half of my career was in startups.

So the idea of like you know everyone you know you wear many different hats in a startup right like I I absolutely believe this and so it's not that you know product people can only do product stuff and developers can only think about developer stuff like it's pretty frequent that you got to think about the full full range of things but in this scenario I would say hey look if you have product managers one of their focuses and like things that I would hope that they they have a really good skill set around is like is trying to represent the user like how can we as product managers make sure that we understand what our users want and like get ahead of that as well like right what are their biggest challenges if we were to make something for them or solve a particular problem this is something where they would be like hell yeah like I would want to exchange money for the thing that you are solving right?

Um, and then really like representing users that way. But that means like, you know, interviewing them, collecting data, market research, like there's a lot of stuff that goes into that. And um, I don't even want to talk about that like I I fully understand all of the things cuz I certainly don't. But I do know that it means representing the user effectively. So um you know if if they're not scaling throughput the same way that developers are I would say how can you you know again think about it like a pipeline. How can we take some part of the pipeline that's downstream from product management and maybe say pull a piece of that back so they can collaborate with the product manager. How can you have a developer start showing product managers maybe some ways that they could um scale up what they're doing? How could you have it so that maybe maybe your product manager someone who's like I have a bunch of ideas and I'm not sure how to leverage AI.

Uh or you know I would need to see a prototype before I could even you know talk about this further and so like don't have time for that. Let let me just continue on. like is there a way that you could have a developer kind of partner up closely with them um help them optimize some of their workflow, scale up some of their workflow um and then the the synergy there. Got to love buzzwords like synergy. um is that you could have the product manager, you know, impart their wisdom about, you know, how they're finding um you know, market market research, customer needs and things like that. Like what are they doing uh or trying to do and have that be sort of imparted on the developer as well and then the developer is then able to sort of uh better work alongside the product manager.

You could even rotate these people so that you bring back sort of more um product or user proxy kind of focus back to your engineering team. And I think that can be super powerful. So, uh, as I'm getting closer to CrossFit here, just to kind of wrap things up, um, I think that you can either in situations like this, continue to lean into the throughput of the development team that that you've been able to to harness, which is which is great, and have them focus on like optimizations for the things that they do. And I think that that's not necessarily how do we just code even more but you know how can we look at spots to save money or get agility in terms of um delivery and uh mitigating incidents hardening on security so on and so forth. There could even be like observability to feed back more data into the company.

And then separate from that and if you're truly looking for like shipping more value uh to users end to end uh I might say like how do you get some of those developers to partner up early with uh with the product team because I think that could be a huge uh a huge value ad. Um, and just, you know, final note, the the whole thing I was trying to avoid is like, um, we don't just want to like code more things and assume that means more value added to customers. Um, and I don't mean to imply that developers aren't capable of identifying value. I just wanted to be careful about my my wording on that. So, I don't know. Those are a couple things that I would consider. Uh, I'm sure there are many more, but um, hopefully that's a helpful thought exercise.

If you have different ideas around that, leave them below in the comments because there's a lot of smart people that watch and I'm sure you got ideas beyond what I just said. So, with that said, I'm at CrossFit. Thanks for watching. Um, if you got uh questions about career development, software engineering, stuff like that, also leave those in the comments or go to code.com and you could submit stuff anonymously. Thanks for watching and I will see you in the next one. Turning off this camera is so much more awkward because there's this little tiny switch and I can never find it.