This is part 2 of an episode we recorded live on a platform called Fishbowl. In the second half, we took questions from the audience, and ended up offering a lot of advice to folks who aren't technical but have to work regularly with developers. We discuss how to communicate with your engineering team, why you might be getting some rather negative vibes from them, and how to improve the rapport.
If you want to catch up on the first half of the episode, you can find it here.
Paul Ford No engineer has ever come into a situation and said, 'boy, the people here before me were great, thoughtful, empathetic developers.' Like everybody comes in and swears—
[intro music]
Ben Popper Build your health app on the most accurate data available. The Health Care Locator SDK instantly connects your apps to the world's leading health care database. Add provider names, locations and specialties in just hours. Visit healthcarelocator.com to download today.
BP Hello, everybody. Welcome to the Stack Overflow Podcast. This is part two of a special episode, we recorded a live conversation with a service called Fishbowl, so give it a listen. Hope you enjoy. Part one came out yesterday. So if you haven't heard that, you can go back and check it out. And then listen to part two, or just dive in. You'll kind of start in the middle. It's myself and Paul Ford having a conversation together. And with members of the audience talking about all things software and technology live in the Fishbowl.
[music]
BP Anyone out there want to throw us a hardball or a softball? Oh, Becky!
Becky Hi, Ben. Hi, Paul. It's nice to meet you. I'm Becky, I'm actually full disclosure, I'm on the Fishbowl team. So we're glad to have you guys here this evening. I actually don't have a technical background. So my question is not going to be about software. But I do have a question. As someone who's new, just probably a year in at a tech company. How do you forge better relationships with developers and engineers? You know, I work on the media relations and marketing team. And sometimes there's a need to communicate with them to express certain things I'm looking for in regards to press or marketing, and also kind of learn the language, right, that they speak. So how do you create those better channels of communication?
BP Oh boy, oh boy.
PF Oh this is great.
BP This is a hard one.
PF Here comes the next half hour.
BP Yeah, we could go on for—I mean, go ahead.
PF What would you like to communicate? Give us an example of something you're having trouble getting across? And you know, take a second and anonymize it if you, if you need to?
Becky My gosh, well, I don't honestly, I haven't had any, any area where I've had trouble, I think, I think it's just I know, they speak a certain language, especially for actually, for example, you know, there's all of these new, we do new releases quite regularly, right, for our platform. And you know, the product is constantly changing all the time. And I think one thing is, especially in the marketing and media relations side is you always want to hone in on what's going to land with media. And I think it's hard sometimes to express to engineers and things like, because they're moving on so quickly, to kind of inform you as to win, this is a big product change. And this could be potentially something that could, could land well, or should be communicated to certain audiences, you know, they're moving so rapidly, and how do you, how do you have those discussions where you're like, hey, when this happens, let me know or—
PF So first of all, this is a very startup problem, because for the most part, if you're in a large organization, and you're shipping an app, you're not directly interacting with a lot of engineers, you're usually interacting with the product manager who might be design affiliate, it might be engineering affiliated, but ultimately, they're the person who's responsible for the product as a whole, as opposed to dealing with someone who's specifically kind of taking and launching and writing feature. So you've got a specific challenge, you have, you actually have a complicated prioritization challenge and communication challenge, because engineers are not driven. Like their success is not your success, their success is, I made it simpler, I got the bugs out, I wrote the unit test I met, you know, I met their KPIs are really not yours. So if this is an environment you're in, and you don't have PMs nearby who can kind of translate for you—
BP You need a liaison in between who can speak both languages, that has been key. And the other thing and I will acknowledge all of my privilege here as like a cis white male who loves Magic the Gathering, is that if you can find other areas, you know, like that's what it was like at Stack Overflow, sit down and play Magic the Gathering, hang out at lunch and talk about anything, and then forge relationships with engineers that way. And then, you know, the casual sort of chitchat about what's coming up in the product and when they might write or write a blog or come on the podcast is easy.
PF Which is really hard during a pandemic and remote. Yeah, you've got to, this is an actual challenge. And the challenge is not even personality or temperament or anything like that. I think it's also real, I mean, Magic the Gathering aside, right like that. Well, we'll talk about that later. But like you're a success. metrics are just so different than theirs, right? So you there is no way forward without conversation in which they can build some empathy for you. That's so like, if I was in your position, if I was advising you and advisor your org, what I would say is like, whoa, Becky, you're not going to like this one on your own, your boss needs to, like work with engineering and be like, 'Hey, Becky is like new to our world, we need to help her out, we need to help her communicate here, outward, because that's really good for the product. I know that's going to be some drag, when you need to think about how things are gonna play in the media. But can we be on the lookout?' And you know what? So now, what are we on the lookout for we're on the lookout for like interesting things to communicate our cool new features things we can alert the press about, things that might be risks, things that might annoy users that we want to get in front of right? Now I would start the Slack channel. And it would be sort of like either media updates are something where people would, if you want to do this in such a way that you would get more signal, even if it's not super clear, I'd almost create an emoji. The emoji could be like a little newspaper or something like that. And whenever anybody tags conversation about a feature with that emoji, it goes into a channel, that also can be a chat channel, about like media related stuff. So what you're doing—
BP Paul is scripting this out as we speak.
PF What you're doing is you need to train people to pattern match for things that might be relevant to you, right, you're not, they're not going to do your job and their success metrics are different, but they can keep an eye out. And most people are pretty well intentioned. And they're glad to. We have a bunch of channels like this, which are like, what needs to go in the blog, what needs to get updated emoji and sort of flagging, it means that you can create these sort of automatic filters. So I would almost do that as like a first pass would be like, look, Becky needs a little help. Let's keep an eye out. Can everybody keep an eye out for things that are might, you know, might play well in the media, she's going to start talking about some of the things that work really well. And I would find, I'm going to bet that channel will have 10 things in it every couple of weeks, that you can then act on, talk to people and follow up. And that's, that would be a way to build a relationship inside of a pretty typical modern engineering work.
BP And Paul mentioned PMs, like I think, you know, project managers could be a liaison there. PM could also be Product Marketing at Stack Overflow, I think actually does often sit in between engineering and marketing. And it's in the weeds, understanding what's being built and what features are coming and what clients are asking for, you know, what's what, what we're trying to how we're trying to position ourselves in the market, and therefore, you know, how we might want to lean one way or another with the delivery of a certain feature. So that's another person I think, who could be the connective tissue kind of between engineering and marketing.
PF Very normal challenge, high velocity, engineering driven work.
Becky Thanks, guys for answering my question. I will say we have an excellent engineering team here. So this is by no means me complaining, just trying to figure out how to work better and more collaboratively. Do you guys have any tools, resources, readings for the non technical person developer?
BP Listen to the Stack Overflow podcast, obviously. And then Paul, I'll let you shot some out. But I would say Dev.to, Hacker News, r/programming, Free Code Camp, some media that you might be able to understand. But also see what people who are just starting our learning that's helped me.
PF I'm going to do something really embarrassing, which is tell you about something I wrote. Just type in What is Code? Paul Ford into Google. I wrote an entire issue of Bloomberg Businessweek, about five years ago, it literally is, it's me explaining programming to middle managers, and it's increasingly out of date.
BP It's still award winning, Paul. It's still award winning.
PF Yeah, it is. For whatever reason, very few people actually set out to explain programming to other cohorts. They mostly explain how to become a programmer, as opposed to like, what the hell are they doing all day? And so that was my earnest attempt to do that. And you might find it helpful. I've actually, I wouldn't normally recommend something that it feels tacky, but it's definitely something that people have come to me and said, like no, that that helped me figure out what was happening in my company. It's really, your altitude, the one you'll you know, you want to stay away from a lot of engineering because that gets down to details very quickly, where I would spend more time as you know, another good book that would be good to read would be the Matt LeMay book about product management from O'Reilly, which is just sort of like how do these things come together? What is product management and that gives you a concept of the whole product, and how things fit together.
BP And then you can speak authoritatively, about you know, the how the building blocks should come together and when you need to sprint and you know, when somebody might do a pull request or branch and suddenly you sound very official.
PF Go get a GitHub account and see what you can learn too, like that's literally that's the culture is people using GitHub all day.
BP Exactly. Ali, welcome to the live chat. Thanks Becky.
PF Welcome to the bowl!
BP Welcome to the bowl, we're bowling a perfect game. Ali, what can we do for you?
Ali I was really struck by the kind of overall just consensus that the goals of the organization and the tech team are, and I call it the tech team. Sorry, I am not techie at all. I'm pretty sure our tech team hates me, because I have—but why aren't those goals aligned? And how can we align them?
PF Oh, yeah, I mean, this is the great struggle, everybody is dealing with this. So you can, you need a good product management culture, you need any basically what you need is a shared understanding of success. Small teams work better than large ones, so they don't get so territorial, lots of interdisciplinary work. But it's a cultural thing. It takes a long time. Like, if you have a culture where a product manager and an engineer and back end and front end work together. And designers come together in small teams, achieve things, ship software, and get feedback from users. You build and share, then you're working and collaborating with other parts of an organization, people have a kind of observant and sort of respectful mindset, you can get really far really fast, but you need leadership to put that stuff in place. And without that leadership, it's hard to build it yourself. You can, I've seen people do it, I get people emailing me asking for mentorship all the time saying like, Hey, I'm going over here, I need to get them to believe in my idea, like, how is that going to work? But it is in a very big organization that doesn't have a product driven culture. It can be an uphill battle, I hate to give bad news, but it can just be an uphill battle.
BP Tell us a little bit about what your company is or does. So just so we can have some context.
Ali Tech meets healthcare.
BP Okay. So I guess one thing that Paul mentioned, which I think is important is that like, engineers want to feel like they are building something towards a goal or a purpose that they believe in. And so understanding like, what the development team, what their desired outcome is, like, what do they think they're building this product for? And if it was done, right, you know, what would the, what would the outcome be? And then from there working backwards to? How can we get that to align with other business goals? And deliver it on time or on budget? And then how can we support them in doing that? I think a lot of the time, what makes engineers really angry is when it feels like it's handed down from on high, build this because we've decided this is the right solution. And there, this is I could build this a million times better. And anyway, this isn't the right solution.
PF The deadlines are bad, the budgets get cut, things get outsourced, but there's no clarity as to how the outsourced relationship is going to work. Vendors show up. There's all these things that happened to engineers and it they get very, very demoralizing.
Ali I do have one more question. So how does it feel from an engineer's perspective, to come in and, and deal with something that's kind of been, like, let's say, database has been already, you know, erected, and you've got a database, and that database has been changed and changed and changed, and then you have a team to come in, to work, you know, with these goals in mind, but have to work with this database?
BP Yeah. I mean, to give you a metaphor, we run blogs and podcasts like this all the time. But like one of the things that is always successful as a blog, is to talk about technical debt and legacy code and how frustrating it is, and why it's not your problem, but you've got to solve it. And so here's the herculean, here's the great, you know, Hero wins in the end narrative of how we finally transitioned off this old crappy system. And so like—
PF No, there's there's a new book about legacy code that just came out, I have it downstairs second, but the title is, is Kill it With Fire.
BP Yeah, exactly.
PF No engineer has ever come into a situation and said, boy, the people here before were great, thoughtful, never empathetic developer. Like everybody comes in and swears and yells. I've been the engineer on the other side. Remember, I handed a system over to somebody. And about a year later, they said, look, they kept asking me and it was a real hostile relationship. And about a year later, they wrote and they said like, once again, I realized that there was a very clear logic to why you made this decision based on the constraints of this organization. And it was a sort of beautiful moment, I ended up going to his wedding. [Ben laughs] But no, it's it's horrible. You get you inherit a bunch of stuff. Often you're not quite sure what it is. And then you need to be productive very quickly, and you just can't figure out why they would have done it as stupidly as they have. And it tends to be based on decisions that were made 5, 10 years ago, so and then you become the next person who, who's going to hand over that hairball of garbage to the next people who will curse your name. And that is the beautiful cycle of engineering culture.
BP So yeah, they're going to have strong feelings about it, like Paul said, and say, 'I know you're inheriting this, what would you like to see it look like? This is what we want the outcome to be? How can we sort of get there together?' is key because the database example you brought up is, it's perfect, you know, like, it doesn't, it doesn't take much to imagine what you're talking about. [Ben laughs]
Ali Right. So I guess what I'm saying, would you rather come in with something that's already there, but not perfect? Or would you rather build something?
PF Oh, engineers would always rather build.
BP Yeah, they want a clean slate. But that can be expensive.
PF Yeah, always be very be always be very careful when engineers are like, you know, we want to work on that it looks really fun. Very, very dangerous. Look, I mean, you know, if you want to protect engineers, you want to connect them to where the money is coming in and say, let's make this part really good. And then they can go build whatever the hell else they want. But as long as that revenue is coming in, everyone will be like, great engineering team. They're really smart. They know what they're doing. If anything that they do is late, slowing down revenue, slowing down the ability of the organization to achieve its mission, a clock starts ticking, and it's a terrible clock.
BP I'm going to tell one story that I heard recently at one of my favorite podcasts, the CoRecursive Podcast, and it was about a team that was at Apple, when they were first building the iPod, and they had a software or like firmware team, and then they had a hardware team. And so they were doing, you know, all these different iterations of the devices and moving them forward across maybe updates and the software. And the software team kept saying you need to allocate resources and time to give us six months to go back. and yeah, clear out all the cruft and all the things that are buggy and broken now, because we built multiple layers on top, and the hardware team kept saying you're lazy, there's no way we're going to devote resources to this in any way doesn't mean we sell more iPods, or whatever it was. And that kept going until it broke, like until the point where the software was, you know, hadn't been fixed in so long, and it started causing serious issues. And then like Paul said, upper management started yelling at everybody. And so that's like a good example, even between two engineering departments where this kind of dilemma comes up of we want, you know, to take ownership and fix things and guidance and direction versus what do we need to do to get to the KPIs that you need to get to those numbers we've been assigned.
PF To take it up a level, there's a guy named Steven Sinofsky, who was responsible for many of the later versions of Windows after Vista, he was the person in charge of windows and like, he'd sort of fixed Windows after it was a mess. He's got a mailing list going on sub stack, and it is all about how Microsoft build software. And it's real nerdy. But at the same time, it's like teams that are not shipping everybody's at war with everybody else. And he actually kind of gets into the why of it. And you realize that some aspects of this complexity are just really built into software, like it's just part of doing something really abstract. And there's a lot of market pressure and you try to get it out the door, these situations just come up over and over and over again. And here he is in the 90s. And he's describing things that we're doing with, you know, front end web components in 2021. And it's a struggle.
BP Ali, I want to say, thanks so much for your question. It really set us down a good path. And I enjoyed this part of the conversation.
PF Yeah, thank you.
[music]
BP Alright. Well, thank you.
PF I gotta, I gotta get these kids to bed.
BP Yeah, Paul, put your children to bed. Thank you to everybody who joined and who listened. It's great to have you come out. If you want to check us out, you can always listen to the Stack Overflow Podcast. You can find that on the Stack Overflow blog. I'm Ben Popper, the Director of Content at Stack Overflow, you can always find me on Twitter @BenPopper or email us podcast@stackoverflow.com.
PF That's right. And I'm Paul Ford. I am friend of Stack Overflow. I am the co-founder of Postlight, a services firm. If you're an engineer, product manager, designer and you're looking for work, check us out postlight.com. We've a good equitable, kind, remote friendly, work environment. Please definitely get in touch. We're growing as fast as we can.
BP And as soon as this call ends, immediately send Sara Chipps a LinkedIn request, could be, you could just say whatever you want in there, but I want 100 LinkedIn requests. [Ben laughs]
PF It is true. Get with her on LinkedIn. She is, she is looking to build her professional network. So congratulations, Sara. So thank you, everybody! This was fun!
BP Thanks Paul.
[outro music]