Soft Skills Engineering - Episode 15: Working with non-technical people and keeping up with the latest technology (with Brad Green)

Episode Date: June 20, 2016

In episode 15, Jamison and Dave join Brad Green, engineering director at Google and Angular team manager, to answer these questions: How do I deal with non-technical people at work? I often get questions that put me into a position where I have to explain really basic concepts to non-technical people like sales and marketing. They seem to rely on me like a crutch, and it gets tiring to have to explain things over and over. How do I strike the right balance of being helpful, but not so helpful that they become dependent on me? I want to be helpful, but I don’t want to spend 90% of my time acting as tech support. How do I keep up with new technology but avoid being sucked in by hype?

Hello, everyone, and welcome to Episode 15 of the Soft Skills Engineering Podcast, the podcast where we talk about all the non-technical sides of software development. I am one of your hosts, Jameson Dance. I am one of your other hosts, Dave Smith. And today we have a special guest, Brad Green. He is an engineering director at Google. He manages the Angular team, and then he does a bunch of other stuff. Did I get any of that right, Brad?

That's all exactly right. Thanks for having me, folks. Ah, good to have you. Let's just dive into our first question. So Dave, do you want to ask it? Yeah, sure. So this question says, how do I deal with non-technical people at work? I often get questions that put me into a position where I have to explain really basic concepts to non-technical people like sales and marketing.

They seem to rely on me like a crutch, and it gets tiring to have to explain things over and over. How do I strike the right balance of being helpful, but not so helpful that they become dependent on me? I want to be helpful, but I don't want to spend 90% of my time acting as tech support. Yeah, it's tough stuff. You know, I think as engineers, we're often very far down in our stack away from explaining stuff to other folks. And so to pop up, it is a big drain.

It takes me a long time to get back into coding, into the zone. But I actually think there's a lot of value in it, both for them and for you. um for for them it's you know this is stuff they don't know and for you you know you're you're trying to do something bigger than you can do alone and like you know your work may never see the light of day you may be doing the most fantastic code ever and if it doesn't get out there and get used then you might as well not have done it yeah but isn't it don't i just want to write awesome code i don't care if it gets used the code is its own reward there is that perspective we live in this this world of driving value though i mean

like what i might as well i could write something else or i could go carve a rock that i've put face down and nobody sees it i don't know but if it's beautiful if it's beautiful to me it might be enough they also talk about spending time as tech support so maybe maybe this is like hey how do i print this pdf oh boy instead of like hey can you help me understand that's why this product printer is not a task anyone enjoys yeah and i don't think anyone actually knows how to do that no yeah it turns out we doesn't matter how technical you are cannot be done maybe they're being like nerd sniped into someone is just giving them a technical problem and they don't understand it but they can't pass by not understanding it so they just like go and figure it out and they

feel hijacked like hey i can't figure out how to configure this printer can you solve it and they don't want to be like no i i can't i'm just a developer like yeah and then they spend two hours googling installing drivers and then i'm gonna choose to interpret this question a different way good choice i think you're right which is which is hey actually it is attacks and it is annoying when i have to pop up out of my stack you know i think if this is the case where it's hey, how should users view this thing we're building and what is it we're trying to accomplish with this part of the software? I think it's actually valuable to me as a coder also for understanding

what our users need because whether I'm front-end or back-end or building hardware, I actually need to know this if I'm going to do a good job because if I'm not using it, and a lot of folks work on software that they're not primary users of, I really need to have some way to have a model for what is good for my users and what's going to be really helpful in their lives absolutely I totally agree with that Brad you kind of mentioned this before when you were talking about the the give and take where if if you don't talk to the product people it can be really easy for non-technical people to design and sell solutions

that have pretty big technical constraints or downsides and and that's not a thing you want to get stuck with either like they just come back and they're like hey so the customer uh said they just needed this thing that can like look at this image and then interpret it into a space shuttle and you're like well uh i guess i'm talking to a google engineer so you're probably more okay with that than like we do that all the time yeah like oh that's that's the same everywhere uh we have all these and i think the thing is like needs to be a discussion like you know the you know folks on the outside have valuable info folks doing development have valuable info like we need to pull together yeah yeah absolutely that's an opportunity for you to get feedback as well

one other thing i was thinking of is meetings get a really bad rap and and lots of it is deserved but if you are worried about kind of getting interrupted all the time and tapped on the shoulder uh a meeting is not the worst way to solve that problem oh yeah instead of every time someone has a technical question they just come and bug you if you just have like a scheduled 10 minute meeting then you know you have to focus on this thing you know you can plan around it and then you can just get it done uh and that's kind of a way to batch up the interruptions office hours set it up so you can uh i know at this point my schedule it's not coding time i'm gonna get some coffee and yeah let's go get caffeined up and do this totally yeah

so i have a little story i used to work at a company where literally 90 of the staff were engineers or former engineers and our customers were engineers it was very technical and you know my manager was an engineer the ceo was an engineer and so as a result we didn't really have a strong sales or marketing team or any really because it was like oh we understand our customers it's no problem we don't need like ancillary support people and i worked there for enough years that I developed a bit of a prejudice against sales and marketing and basically anyone non-technical. And then I changed jobs to a more typical product development company that produces actual software for non-engineers, for pretty much anyone to use. And I encountered an amazing

sales and marketing team. And these people really knew their stuff about marketing and sales. And I was just blown away because prior to that, I thought, ah, I'm an engineer. I can do their job. I don't need to help them. You know, like I don't even need them. It's kind of what I thought. And then when I actually encountered a real proper professional sales and marketing team, I was just floored with how good they were at their job and how I'm like, I could never do that. And, and I, it really opened my mind to being a willing to like share information with these people. And, um, and I realized like they need information for me and I desperately need them to be successful and so it helped me to get into this mindset of like yeah i will take time with

you and explain technical stuff or whatever you need you know because i know you're contributing a hugely valuable uh part of our team yeah absolutely and you know some of this might be stuff you can help with like if if your sales marketing team isn't that great you might in a polite way explain some things you think could be done better oh yeah this engineer comes in hey guys i got an idea about how to trick your business yeah well do you think we've answered this question have we have we shed light on the i think we have i think there's probably more that needs to be said here like um i mean i think we've talked a lot about the mindset and how it can be hard but like and we've only talked about one technique for really making it better which is

try to batch these things into like a meeting where you have like a regularly scheduled time But what do you do when someone comes to you and they're like, hey, how do I click this button or how do I use this feature? And you're an engineer and you know there are channels for them to get this answer, but you don't want to be rude. Well, are there? Well, there could be a FAQ. If it's not all long-tail questions, it could be recorded in one place. Good idea. Maybe produce some documentation for them.

yeah not that people will go there if they know where you live and they've asked you a question before see yeah that's true that's the balance that i think is really important to strike because as engineers we sometimes like so far we've talked about it being annoying but sometimes we just want to be really helpful so people come to us with questions you're like yes i can help you with this and then they just keep coming back right they're like oh i know dave he always answers my questions and so i'll go to him um and so there is a balance to be struck there and i think producing documentation or having like a a help channel um where you know some means where people can actually get answers to questions without having to go directly to the engineers

every time um can be really helpful i think an faq is great idea for that and even maybe having like a designated helper on the team it's like okay this is your week to end to field questions from uh people outside of engineering this is also a thing i've seen done by some kind of tech lead role where um they they kind of shield the team a little bit more from interruptions and distractions and so part of their job is to know all the kind of technical stuff that's going on and also communicate that to other people i don't know if that's how it works everywhere but um and that doesn't mean that you can never ever like the engineers are these zoo animals behind the glass you can never talk to but but it can be helpful to have an expectation that there is

some defined role who deals with more of this stuff it's true but then it sucks to be that person really maybe maybe that person likes that kind of thing yeah that's true i think it's hard for them to grow them it's hard for them to have technical time to deep dive i kind of like the rotation idea better because you know everyone needs communication skills work we cannot be too good at it oh okay so it's just kind of a maybe i wasn't listening earlier uh so it's just kind of a role that someone takes on for a while yeah like maybe you've got a team of five engineers and you each take a week yeah that's cool so it's almost like on call but on call for the product people or the sales people our slot this week just here's yeah maybe have like a rotating

dock here's questions that have been asked here's what's likely to come up that's cool yeah and i think the faq is a great idea because it's like in addition to a rotation where you can like be the person who fields questions you can have like a write through cache of this faq where it's like oh you know this is already answered in our faq check take a look there and if it's not already answered guess what you're on the rotation so you'll be writing the answer yeah that's a great idea okay so to sum it up and answered yeah to sum it up there there's some attitude things where you can kind of work to develop more uh empathy for the product people and understand that talking and communicating will lead to better technical and product decisions and then there's some kind

of tactical things like uh batch up the the meetings have office hours have a rotation so it's not all dumped on one person have an faq hopefully some of that stuff helps yeah cool all right i will read the second question um this is from antonis he actually had a question the other week yeah this is a good job antonis double question i didn't realize that when we picked this but i recognize the name all right how do i keep up with new technology but avoid being sucked in by hype dude hype is all there is this is specifically about javascript frameworks right if it's hyped it's probably really good and you should just do it yeah that's true how could that many twitter thought leaders be wrong though really well that's how it works

with music right like it's it's the number one song so it's a good song it must be good yeah and you should switch to it uh so dave and i have dumb jokes brad had wise thoughts about this maybe we should hear brad's wise thoughts it it is you know i i may feel like the world is passing me by if i'm not looking at the latest and greatest thing you know like i'm i'm on angular one or i'm on backbone or i'm on you know something that isn't the latest thing right now i you know i think there's there's a new technology every day because these things are fun and semi easy to write to get started i think the the important thing for me if i'm thinking about like put my career building hat on what what do i want out of this well obviously i can't go adopt

every new framework every new library whatever tool that it is interesting i think though to figure out what what kind of problem are they trying to solve and what what are the patterns inside it that are interesting because it might mean that those patterns are attractive enough the infrastructure they've built around those patterns are valuable enough for me to want to switch which is a giant cost often alternatively it might be that these patterns are something i could use in the current stack that i'm on and you know i think it's the the that thinking that's replicatable across whatever current technology that i'm using that's really valuable to me because those are the skills that that i grow with over time as an engineer i really like that

thought so you're saying you look at like elm for some example and it has all these cool ideas and and some people might look at it and then look at their code base and be sad because there are all these things that are in elm that you can't do and you're saying uh and then it's it's tough to just like throw away everything and rewrite it in some new framework and you're saying look for the things that you can take from that and apply it to your to your code base instead of just say, like, boy, I sure wish we were using this other thing. Sucks we can't. Yes.

I really like that, too. I had a friend a few years ago who decided to get a master's degree in computer science. He had been working for, like, 10 years. And talk about, like, the ultimate problem here because it's like you're learning all these new concepts and you want to put them in place, but you can't. Now, master's degrees aren't really known for new technology, but it's, like, the same kind of problem. And what he told me was like six months or to a year after he got his new degree, he says to me, you know, I can't point my finger specifically at like any particular technologies

or tools that I'm doing differently now, but I have taken principles from my new education and applied them. And he showed me a few examples and I'm like, that is so cool. And maybe that's the same kind of thing we should be doing with new technologies rather than saying, oh man, I got to get on this new whiz bang tool. Instead, understand the tool, figure out what makes the tool great. and then see if you can build that into you instead of building it into your product directly.

Yeah, there's a saying about, like, given semantics or syntax, what will people have opinions and argue about? And it's always about the syntax. Where the semantics are really the interesting thing because it's what allows for a good architecture or not and it's what allows for me to understand what I'm trying to express or not. And, like, JavaScript is famous for being able to be flexible with semantics and allow me to take on these new idioms

really in whatever particular library I'm in. So there's this concept called fatigue that we hear about a bit in the JavaScript community anyway. And I know Brad leads the Angular team or manages the Angular team, so we're talking JavaScript a little bit. But let's talk about that because I've actually been feeling that a little bit lately where my team had just begun adopting Redux, which is this new hot framework for managing your data in your front-end web app and then

suddenly this new thing just hit the scene called mob x and it's like everyone's talking about how awesome it is including the author of redux and i'm just like oh man here we are again yeah and so i think it's important for you to just be like look no like okay i've been on this merry-go-round like you know i've gone around the block four times now no let's just stick with the tools we have and see what happens you know build there are you familiar with the the hedonic treadmill or hedonic adaption i don't think so that sounds like a five dollar word it is a five dollar word i'm about to make myself sound so smart it's this idea that uh humans get used to things so you have a small crappy apartment you move into a really nice apartment and it briefly

makes you happier but eventually you just get used to it and then you're not really any happier in the absolute you're just like your apartment is nicer but day-to-day experience is is about the same and i wonder if there's that same kind of thing in technology too like you you change to some new thing and maybe it actually is like in some absolute sense better um at some point you just get used to it and then you don't notice that it's better anymore and then you keep looking for the next better thing oh interesting interesting yeah i think we're all guilty of that it's like new is fun right new is perfect also because i've never run into the real problems in it yeah yeah yeah yeah no one has written the angry blog post about why i'm leaving mob x because it

has all these horrible things because no one's left it yet it's only a few months old that's that's that's a couple years away still there's also so there's the the kind of positive side where new is really attractive and then there's also this negative side where it can feel painful to be left behind yes like the world has moved on without you yes and there's a very real cost to that too because if you are using technology for example on the web that's 10 years old you will have a very hard time attracting and retaining engineers for your team yeah that's just how it is but also i mean brad talked about backbone or angular one i bet there are just gigantic piles of teams still writing backbone it's just that it's very well understood and and

people aren't talking about solving like crazy new problems in it anymore look if you're if you're in finance you're still likely writing cobalt yeah yeah yep yeah so there's there's kind of a disconnect between where the hype is and where the people actually are yeah and the hype definitely leads the adoption by a huge margin so you can feel like oh man i'm behind i'm not on mob x yet no one is even using redux yet people are just talking about it a lot but a tiny percentage of people writing react apps i bet are using redux or or angular apps or whatever yeah yeah so some of it is recognizing that uh you're you're not behind really people just like to jump ahead the other thing that this hype uh cycle does to your mindset is it makes you focus on the tools

your yield that you're using to build the valuable things you're building instead of the valuable things you're building and i think as engineers we often take our eyes off that prize you know like brad was talking about earlier like we're in this value-driven state or at least we should be instead of looking inward and saying, but yeah, but the screwdriver I'm using to build this tool or this product is a crappy screwdriver. But it's like, think about the end user. They don't care what technology you're on.

Try to take more pride in building something awesome for your end user than you do in the tools you use to build that thing. Totally. I mean, it's so easy to get in the trap of, I built some great technology, and now I need to find a problem for it to solve. We do that here at Google.

i mean we love technology it happens yeah it's it's also uh if you jump from new thing to new thing it's hard to get deep into a product kind of going with what dave was saying if if you build a to-do app in every new framework it's hard to really like polish and make that the best to-do app ever because you have to throw it away and start over with every new every new thing that comes out so um i think you can build a lot better and more solid products by diving deeply into something let's talk a little bit about how you actually take time to learn about new tools and technologies and really assess them instead of just reading tweets about them how do you do that you know i i someone i used to work at this company called next computer and i remember

there was this guy named Alan Markham there. And he made a point, this was, you know, I had been at work for a year 1991. And he said, hey, look, as a software professional, part of your job is to go be learning new things. Go be building on new technologies, learning these new patterns. Because if you're not, you're actually not really a software professional you're a coder's assistant oh assistant to the coder which yeah like because

you know if i don't know enough to think about architecture and design and have a whole bunch of techniques i can use then i either just implement with rudimentary skills or there's someone else at my company who is dictating that stuff and i don't ever get to grow into it I think we should have a lot of motivation to go do this. Enlightened companies will give me space to do it and actually have a culture of sharing knowledge. Maybe I could bring that enlightenment to my company. If not, I do have to do that on my own.

I have to make space to go do it somehow. Open source projects are a nice way to do it if there's things that I can go contribute to. But it is hard. it's hard to make space and have a balanced life is that i think a lot of oh go ahead no no you no no no you okay is that something that google explicitly does i know there's a bunch of talk about 20 time uh how how do you do that is that a team by team thing or is it a company-wide thing or we used to have 20 time and what what we found was that uh you know we used to have this thing

called the Project Database Insight Google. And at some point, there was two projects for every engineer. And so you can assume that they were all great, but no, they weren't. That's huge. And so we don't really have formal 20% time, but we still have this culture of learning new bits and sharing them with tech talks. And I think if you approach your manager and say, hey, I really want a week to go investigate this new thing, it's pretty easy to get. but the model i like better is where we have a sort of team-wide like innovation week or hack week or something where in a group i can go explore things because i feel like i get a lot

further if i if i try to build something bigger with a team sure yeah that's uh that's what we do at my current company there's a week every quarter where the whole company just just does whatever they want and you have to kind of show something off at the end of the week so you can't just go play badminton all week but uh badminton week yeah the constraints are badminton week are very there aren't very many constraints i guess you just get to pick some problem try and build anything to solve whatever problem is interesting to you and it is are they supposed to be related to the company's mission yeah they're supposed to be related um but that's a pretty it it turns out there are a lot of things you can do and then convince people they're

related to the company's mission it's not a very constrained thing to use new technologies during this time you can some people do some people are more interested in exploring product focused things where they're like just just trying out some new solution and some people are interested in exploring technical things but it's up to up to the whoever's doing it yeah i think it's good it also back to the earlier question it puts the tech support stuff on pause uh because hey we're all focused on this new thing my meetings stop it makes space for me okay there you go yep so that's like an extra answer to the first question just do hack week you won't have any questions anymore so when you're looking at new technologies what kind of metrics do you use to actually

determine is this going to be better than what we currently have i don't think there's any way to No, I think like empirical evidence is the only way. And also maybe don't judge a new technology too early. Just given how much Angular 1 sucked at the beginning. Like people always say, hey, well, Angular just really appeared on the scene and went crazy. And I think they didn't see the first three years of it where it was unusable and horrible. That's a good point. That's a good point.

um i i also have similar experience with the early reaction to react which was like xml in my javascript and then like on click handlers everywhere and and there are a lot of things that um look horrible because they remind you of some horrible thing but it's hard to understand why it's different now at the very beginning you just see see something that looks like a pattern that sucked before and you assume it sucks now have you ever heard of a company that adopts a new technology after doing some kind of empirical measurement on it to to prove that it's actually better in some way no what they do is they build a spreadsheet then they they put numbers and they already the person who's building the spreadsheet knows the answer they want to get to

and so it's always cooked yeah there's no objective evaluation method not really well you see react has five stars in this spreadsheet yeah i added the columns up look obviously you know they say the hardest part about being data driven is finding data to validate your assumptions no i have also never heard of it and it makes me wonder like why are we always chasing these rainbows you know like why are we why is there so much hype when it all just comes down to like well i like it well i think it's because there is no objective evaluation criteria and so then we fall back to well how could i move this thing forward and it's it's help yeah i i think new

technologies at a company in my experience seem to be driven by evangelism much more than by absolute empirical data because like brad said it that's hard to come up with someone just likes it and they're convincing and then other people like it and become convinced so it comes down to marketing yeah i mean there's some things you can do like you could build a benchmark but i've never seen a benchmark that actually plays out at macro scale to mean that much so until you really build the real thing and put it in production it's hard to know as a leader on on my team what i have done and this is actually really hard to do up front you can only really do it after you've chosen to adopt a new technology is i ask the developers

how happy they are with it and basically if i get a lot of nods and smiles and then i think it was a good technology choice and if i get a lot of like you know face palms and and epic size then i think it was a bad technology choice to another problem which is developer happiness doesn't always correspond to getting business goals done like what if they're really happy reinventing wheels because they're on some new technology that doesn't have uh like a uh an express clone yet or a Sinatra clone or whatever, then they get to be the person that writes that and it feels really good.

That's a good point. But that's a solved problem already in many other technologies. So, yeah. I live in fear of making a decision. Yeah, but that old one didn't do the thing I care about exactly right, so. Yeah.

I'm going to go rebuild the math.round function. Yeah. Math.bradround. It's an upgrade. It's so round. So I want to talk about one more thing here. So I think we're pretty much coming down on the side of being on the front, the bleeding edge of the hype cycle is a really bad place to be.

And I'll just give you an example of why that is. So at my company, we are pretty aggressive, not the most aggressive, but we're pretty aggressive about adopting new technologies. And as I think back over the last four years and count the major patterns in our web front end, there are literally four and maybe more um and this is one product right so as a web front-end developer on my team when you jump into a piece of code you might have to ramp up on one of four very different technologies depending on where you land in the code base and that's because it's actually really hard to thoroughly adopt a new technology when you actually have a business with

real requirements you know and so i think it's an important thing to ask yourself if you're considering adopting a new technology is as a business or a team can we afford to fully adopt this technology or are we going to end up with like a melting pot of lots of different technologies and tools in our app yeah it's very expensive to to do a switch or to fully adopt something if you think end to end all of the implications yeah absolutely dave you you said it's bad i i would be a little more i'd hedge my bets a little more and say it's it's expensive um but someone is doing it right i mean every new technology technology some company jumps on it and then writes all these breathless blog posts about it and then they become like the the that technology

company and there are benefits to it uh like recruiting and and marketing and and then maybe some technical ones if if the technical stuff turns out to be really solid but it definitely is expensive yeah i agree with that okay do you want to sum up our uh our thoughts on this question dave uh new technology is awesome you should adopt all of them if they're hyped they're good do it okay did i get it right uh brad do you want to sum up our thoughts on this question So I think the things that I would care most about is, for me, I should take my own education in my own hands. And if there is something new and seems at the top of the hype stack, I should not necessarily think I need to adopt it, but I should go learn what's behind it. What problems are they trying to solve and how are they approaching it?

I think that's really solid advice. Fundamentals. Semantics. I love it. Okay, I think that wraps up our questions for today. Brad, if people like the stuff you say and they want to learn more about you or hear more from you, how do they do that?

I am on Twitter, Bradley Green, B-R-A-D-L-Y. I'm an adverb, green. And I actually talked a little bit about this at an ACM conference in New York a couple weeks ago where I was talking about engineering teams and the power of being inclusive. and that should be hitting youtube in a couple weeks i'll share it on you on twitter cool and as always if you like what we're doing here if you can rate us on itunes that helps us

out if you can tweet about the show that helps us out a lot we really appreciate your support and if you have questions that you would like us to answer direct message or twitter twitter us direct message us or tweet us at soft skills eng and then we'll throw them in the queue thank you so much for coming brad we really appreciate the wisdom that you lend to us oh it was super fun thanks and we will talk to y'all later bye all right thanks everybody