Soft Skills Engineering - Episode 56: Keeping Meetings On Track and Designer-centric Culture

Episode Date: April 18, 2017

How do I keep meetings on track? I work in an agency with a designer-centric culture. How do I make myself heard? Dave and Jamison answer these questions:

It takes more than great code to be a great software engineer. This is Soft Skills Engineering, the podcast, episode 56. I'm your host, Dave Smith. I'm your host, Jameson Dance. Soft Skills Engineering is an advice show where developers write in with questions and we provide answers. But nothing technical, strictly the soft side. It's also weird. We did a live show last week. and it's it's weird to be back in the comforting embrace of my screen away from people

the solitude the embrace of solitude yeah i think i forgot to have stage presence because i'm so used to recording this in my office and i can just like stare up at the ceiling while i think so i probably weirded out a lot of people that were there but thank you all for coming yeah it was a great show and uh i actually had a lot of fun and the audience participation was kind of cool too yeah we didn't even think about it but we just asked questions rhetorically and then people answered them we're like huh oh good answer yeah thanks well i'll see if that works today right now just throw out an answer and maybe someone will pop their head into your office yep yeah uh yeah do you want to read our first question dave yeah sure so uh here we go it says

lots of my meetings seem to have that one engineer who is dead set on pointing out esoteric error conditions that drag the meeting into a rabbit hole of unimportant discussions how do i keep meetings on track while still balancing a healthy respect for the people who want to voice concerns how do i do this without shutting down legitimate discussions and important cases case in point twice this week i've been in a design review meeting where an engineer dominated about half the meeting with error cases that turned out to be unimportant what's worse this engineer is very experienced and has lots of influence i heard other engineers complain later that the meeting time was wasted because we didn't get to discuss some of the most important parts of the design

i'm still pretty new but i'm experienced enough to know that this engineer was wrong to drag the meeting into these rabbit holes what should i do i've talked about before how i'm famously grumpy and impatient in meetings so maybe if you just amp that up and just glare and just i don't know what a grumpy aren't there like little angry clouds over grumpy characters and cartoons or get a cardboard cut out of an angry cloud and just hold it over your head yeah hold it over your head or the anime teardrop is that when they're angry that might be when they're surprised yeah or happy yeah that might be mixed messages anyways just an aura of imminent violence that could solve your problem i'm gonna guess that if someone is derailing a meeting this bad

they're probably not paying attention to your aura your aura isn't strong enough in the book snow crash one of the main characters has a giant tattoo on his forehead that says poor impulse control um so maybe you need to do something like that it's like hey i'm capable of anything if you bring up this little tiny linting error one more time in the meeting yeah your face will be a linting error. Oh, don't do that. Yeah. This is, this is tricky because it depends on your role in the meeting. If you're a manager, it's a lot easier to feel like you can step in and ask people to keep it on track without offending anyone. And even then you still might offend someone, but there's at least some expectation of, okay, like this person can do

that. But if you're a team member or a junior team member or something, then you might worry about people feeling like you're overstepping your bounds or something like that or maybe you're just wrong like maybe these are important rabbit holes that need to be gone down you just don't have enough context to know what's important and what's not have you ever heard that rule well rule is a strong word have you ever heard that guideline about good code where all of the code inside a method or a function is supposed to be at about the same level of abstraction nope i only write terrible code so okay that's a thing uh like if you have some code for reading and writing files i don't know it shouldn't be diving into like low-level bit twiddling and then file system

manipulation okay i don't know it should all be about the same level of abstraction and anything lower or higher should farm it out to a different function that you make sense yeah i think that so i think you can kind of apply that same principle to a meeting that the meeting should have a purpose and and things related to that purpose should be at about the same level of abstraction and if you dive really deep into something that's a good sign that it needs to be in a different meeting oh to not derail things too much does that concept of keeping things at a cohesive level of abstraction have a name probably if it has a name it would be so much more powerful to use in a meeting because you could say hey i think we've we're violating the

x principle i can't tell if you know the name and you're trying to lead me to think of it remember five minutes ago i didn't even know what you were talking about that's still true yeah i'm sure it has a name i just can't think of it uh someone please tell us what the name is yeah because you could drop that name and even in the beginning of the meeting you could set up a ground rule to say hey uh for this meeting we're going to abide by the x principle and we're going to keep the conversation at this level of abstraction yeah and i don't know that that has to be an absolute rule there might be some meetings where you say we are going to solve this problem and we're going to go down as many rabbit holes as we need to solve it all the way

sure sure i think for most meetings that's but in that case you're just saying that for this meeting we're going to go all the way down the abstraction stack yeah yeah right well especially they mentioned a design review meeting which i imagine has lots of different people in different roles and sure the deeper you rabbit hole on engineering stuff the more people you're leaving out that don't understand or care about that yeah yeah exactly you're wasting more time yeah i'm actually super sensitive to this um when i start making comments in meetings uh i will often preface them with apologies do you do you ever do this where it's like i'm really sorry if this is the wrong topic for this audience but dot dot dot and then i launch into my my thing right

you just say it anyways yeah of course that's why i apologized it doesn't count you apologize yeah exactly that's like if you put a comment above the function it's like hey i know this is bad yeah good luck then it counts as good code the following is a hack i apologize yep this is so maintainable suddenly um but but anyway that that's what i do and so i think i think maybe some engineers are more sensitive to this than others because i could imagine other engineers well i can't i don't have to imagine i've seen this it's like they have this notion that they're they have discovered a hole that needs to be explored and solved and and it seems to be very important but

it turns out it's not especially for this particular audience like it's very hard sometimes for some engineers to uh what's the word like balance the importance of the thing that they are bringing up against the particular audience that they're bringing it up with like can these people actually solve this problem yeah yeah we spend so much time thinking about the right way to do things and and it can be easy to get stuck on the correct way like capital c correct and and not think too much like you said about audience or about context or about the cost of correctness yeah yeah i remember there's some little internal api thing that we were making at my one of my first jobs and uh someone submitted pull requests to change it and i found some like little security

bug that if two things happen within the same millisecond then and like they had already hacked into our vpn and a bunch of other stuff but anyways under a very specific set of circumstances like bad stuff could happen and you probably felt very proud of yourself at that i was so proud i was like this cannot stand it's irresponsible and and to change it would have taken a lot of work and i was uh correctly ignored i believe like that it doesn't matter but but i was i i felt myself get trapped by this idea of like this is what is right and people need to know and and it's not an effective use of my time yeah that's true but only in hindsight i just ignore all security things so to avoid that problem you solved the meeting problem though i well there

are different meetings now security postmortems are a little different yep so do you think that the uh when time elapsed for you did it suddenly become less important like in hindsight were you able to look back and say it wasn't that big of a deal uh yes 100 that also looking at wider um pieces of the system or having responsibility for more people i was able to recognize like i don't know just help me put it into perspective like we have bigger issues to deal with then yeah then you're one millisecond hacked vpn security bug yeah yeah so i wonder if i mean there's there's a balance there because sometimes those are real very important things that pop up as little tiny things and then you realize nope this is a big

deal but so i'm not in that case i've seen this concept called uh parking lot in a meeting have you ever seen this uh-uh so this is where like the meeting has a purpose i've seen it used in daily stand-ups um the meeting has a purpose in the case of stand-up you know you're sharing status you're identifying blockers and other things and it's supposed to be pretty fast but then if someone has a topic they want to go deep into you have this thing called a parking lot and you just like write it on a whiteboard you write the word parking lot and then as people bring up topics or think of them they just write they just walk over to the whiteboard and write them down and then the meeting just progresses normally and when you get through the main

business of the meeting then at the end you visit the parking lot and say okay what topics do we have and i've noticed that sometimes people will write down a parking lot item but then by the time the meeting is finished uh they'll they're like oh never mind that got resolved you know and it's like it just naturally happened uh because that you know it was just going to happen anyway and so we avoided derailing the meeting by simply making it a little bit more asynchronous and deferring deferring the uh basically we use lazy evaluation for meeting when yeah okay so so the parking lot is stuff that you think you want to talk about but you're going to hold it until the end exactly okay so so people aren't like responding to what you write with answers

they're just adding more topics when they go right it's just a list of topics okay interesting and i was thinking maybe you could even impose your own little personal parking lot where maybe an issue occurs to you in a meeting and rather than raising your hand and speaking out right away you just write it down on your notes and wait make sure that five minutes go by before you bring it up after five minutes if it still seems like a pressing concern then maybe it's worth bringing it up to the meeting group you know like a self-imposed cool down period yeah how will people know that you're smart and important though if you don't stand up and interrupt them with your concerns i think you may have just found the crux of what's

actually going on in this college situation um there act there is this this idea in fact i was reading an article just yesterday that said like how to um oh what was it it was like how to participate in meetings and one of the objectives was to make yourself look smart like the author just came right out and said it and i just kind of props to them for admitting what everyone thinks already that's true right like on the one hand good congratulations but on the other hand like it just made me feel a little bit sick because it was like what is the purpose of a meeting really is it just a bunch of engineers who are on the same team to come together and and uh like one up each other with how smart they are or are you really trying to solve a problem

like what where's the focus yeah so that made me sad a lot of these suggestions um would be easier to implement if if you're in a position of authority you can just say hey we're keeping this meeting at the same level of abstraction we have a parking lot for ideas at the end that don't fit into the agenda uh please give it five minutes or whatever i mean what do you do if if you're just a humble everyday team member and you see this derailing happening you just get up and leave you just walk away yeah but or flip the table on your way out and then you know just to make sure people know i thought you were going to say flip the situation and take the other person out i stand them up and march them out of the room okay so let's say you're you're a humble

engineer maybe you're a little less tenured than the other people in the meeting this is where you employ in my opinion the tactic of the question where you ask like hey is this like basically you're just trying to baseline hey is this normal like trying to come across as you're curious if this is how things are supposed to go and you can use your newness your new status to um kind of play dumb a little bit and like maybe it's really clear to you that this meeting is off track but if you just ask the question like hey is this the right topic like are we are we doing what we need to do here just want to make sure i understand you know um suddenly people might get introspective and go oh yeah you're right we're we're off track instead of asserting

it right you ask it yeah you got to be a little more indirect maybe i mean it sucks that it is that way but i think people respond better when you ask rather than just like saying you're off task yeah i think that could definitely work especially if uh it feels like this kind of thing happens a lot with kind of the the alpha engineer types where they're smart and sometimes difficult to work with and so you might have to handle the situation delicately you might also just be able to say like hey i feel like this is off task some companies have a culture where um everyone participates at kind of the same level in meetings and there's not like the boss meeting runner person it's just everyone gives feedback and and gives input and then you might

you might just be able to say hey can we do this a different time and focus on the main thing yeah yeah well did we answer it um i think so it's hard it's a hard situation but yeah solvable solvable with the right level of rage yes with the right level of rage and facial tattoos all right question answer i will read the next question i have worked for several agencies with very designer-centric cultures in these cultures developers are treated as second-class citizens reduced to digital construction workers whose concerns on the product are not given the same consideration as those of the designers i believe much of this to be subconscious and i do not like to think of us as warring parties, but I really don't enjoy when my concerns as an engineer are

not given their proper weight in collaboration. I strive to be upfront when pointing out significant technical challenges, but also gain little to no traction. I've failed so often that I've learned the most effective method for moving a designer off of a bad idea is to build the broken idea and let them use it. Once they see and experience the broken idea, they generally change position and the product gets better. I've found no better strategy for handling this situation. My question to you is how do you handle this matt that is like maximum passive aggressive right ultimate maximum passive aggressiveness would be to purposefully build a broken version of an idea that could work because you don't like it okay good and then say like hey look it's it's broken

this is like one step away from that yeah don't do that uh that must feel awful to build something that you know isn't going to work but you just kind have to crank it out anyway yeah that's yeah you just doomed work this is not completely doomed because it's theoretically helping make the product better but yeah but it's just feel it's like a lot more effort than you think it should be put in because you could just say yeah it's not going to work or it could spend two weeks building it and show you yeah so i've never worked at a place like this where design um felt like it ran the company and the developers were second-class citizens i have worked at places where everyone besides the developers were

second-class citizens and it sucked yeah yeah it's yeah i get the impression that's pretty common actually yeah me too i don't know what to do about it but it feels weird um so i i guess the point is uh welcome to the rest of people's jobs in the tech industry this is how like sales and marketing and and qa and support all feel at tech companies just soak it up and develop the empathy so that later when you're on the other side of the equation you aren't a scumbag yeah yeah i'm i'm pretty sure medium sure that the design team is not actively trying to be scummy um how do i put this i feel like i've seen situations like this where um there's some conflict between two groups in the company and and i would suspect that design

has some complaints about engineering like your complaints are they don't listen to our product ideas and so we do extra work and i i bet there's also some complaints about how i don't know the the engineering team never builds the right thing that we tell them to build or they they push back and make us take too much time because we have to go through all these cycles or something but i feel like there's this kind of this communication mismatch where uh it sounds like you have tried already to just say hey i would like to give more feedback earlier in the process and they just might have said no or not done it but it still feels like there might be some room to sit down and say how do you feel about engineering how how how do you feel about working with us what is

upsetting to you and and have an open conversation about it and as part of that you could share this feeling um if the goal is to build better stuff faster it takes a long time to build an idea completely even though you know it's going to be broken and have all these problems so you could save a lot of time if you give feedback earlier and there's probably some things that you could do that would make design happier also so there's some kind of give and take there yeah yeah if you discover their their issues they might be more motivated to um to respond positively to your suggestions yeah totally i i have seen this uh this kind of situation where i've been in the engineering shoes and i've been working with a designer the designer gave me some mock-ups or

some wireframes. And I like I immediately latch on to a problem that I that will cause a usability issue. And the designer is working at like a very high level of abstraction, usually, like user goes here, user goes there, then this happens, you know, and, and I'm thinking, okay, well, what if that first step goes wrong, then the second step needs to change in these three different ways, you know, and the designer just hasn't really considered that. And so to me, it's like, it comes to my mind immediately, right? And I start identifying all these problems. and sometimes i think i get impatient with people because i don't like the idea is fully formed in my own head but i haven't taken the time to really explain it in a way that will be concrete and clear

for the designer and that may be the situation here especially since uh this listener has gone to the extent of actually building the broken thing to show them like sometimes you do need to show them but maybe you could show them in a way that doesn't take the full project time to show them the broken thing you know like whip out a quick prototype maybe do some pictures you know who knows but make it concrete because sometimes this feedback will be clear in your mind but it's just not clear in the other people's mind yeah that that makes sense and and that could help build up more trust too if you do that enough times faster then they might start to require less upfront effort to prove that your concerns are valid yeah exactly and and maybe so like i was

thinking to myself well why don't they prototype this and you know maybe the designers should be prototyping and then i thought maybe this developer is the prototyper so like maybe the designers are coming to you with this expectation that you'll whip it out quickly and then any problems will become obvious and then they'll iterate on the design so like maybe from their perspective everything is working perfectly you know you just didn't realize that you actually are a prototyper not a product developer yeah and and again that's another argument for sitting down and talking about this explicitly i i love that this question asker said they don't like to think of us as warring parties because it's so easy to just put up your walls and i don't know form your

tribe and say engineering is being stymied by the designers who don't respect us and then you grumble about it among yourselves and then you hear the designers grumbling about it and suddenly there's politics and you're not working well together so i love that instinct to avoid that because that's good i i think it's uh it's not the default it will require active effort but if you can do it you'll work so much better together if you have more trust between the two groups yeah Yeah. So at a previous job, I actually had a little bit of a similar situation. And what happened was product managers and UX designers would crank out these really high fidelity mock-ups and wireframes. And then as developers, we would just sit back and build them, you know,

pixel for pixel. And like, they would be super proud if we cranked out a pixel perfect implementation of their designs. Like it was, they were just so happy with that. And so we got this incentive system where our job, where we were rewarded, was to crank out something that exactly replicated what they came up with. And it got a little bit of a vicious cycle because we turned off our critical thinking skills. And we got to the point where we were just building exactly what they said because that was both the least friction and had the highest rewards because we were both really happy with the outcome. um but we just stopped giving critical feedback in the early design phases and uh i think in the end the product suffered as a result of it because we kind of shut off shut that off i've uttered the phrase uh like assembly line programming or something like that you just take

trello feature factories off a board or yeah yeah in a negative light but it also does sound comforting yeah there's a very clear marker for success which is not is the product doing well with users is the company doing well it's like am i completing these very clear tasks fast yeah yeah like does the product match the spec yeah yeah that's that's a lot easier to measure than like are we making money yeah or do people like it yeah like i remember that at one point there was a bug that a customer reported and i went back to the product spec and i was like nope the spec says it's supposed to work that way so you can't log this as a bug in our bug tracker you have to make it a feature request i probably defeated that customer yes we win gotcha that is the worst

yeah yeah it's definitely a lot more effort and not every engineer has to be super product focused but i think an engineering organization should be product focused overall which requires uh better communication because you if you're going to give critical feedback you have to make sure that people aren't offended and that they understand how to take it and i don't know yeah it's just more complex but it feels like it results in better products i don't have any hard data on that it just sounds better sounds good feels good must be true yeah when yeah my gut says it's right your gut does pretty good things though i'll be honest i mean it digested half a pound of popcorn yesterday so that's pretty good yeah it's doing well

when when i talked to my former engineering leadership about this like feature factory situation that i thought we were in you know they were like aghast you know like no engineers have valuable input into this process and we absolutely should not have them shutting down their critical thinking skills just because a product manager or UX designer has presented like a high fidelity design. Instead, they should absolutely be critical and help contribute to this design process. And I would bet that in this situation, even though you're at an agency, if you went to leadership, you might be surprised to hear their opinion on the situation. That's a conversation I would have. Like I would say, what do you see the role of designers and what do you see the role of

engineers do you see engineers as implementing the designs or collaborating with the designers to build the best product some of it might depend on the kind of agency as well there are some agencies that do marketing sites or they're a lot more content focused and then there are some agencies that do more kind of contract product development and it feels like the back and forth iteration between design and engineering is a lot more important in while still valuable in kind of the content site model it feels a lot more valuable in the product development model yeah yeah if you're trying to build a better product faster for a client uh it could save you money and you could have higher margins and and get a better reputation and stuff but if if you're

trying to make pretty things quickly um then then design kind of does run the show there and that could be the case here yeah in which case you could apply soft skills engineering go to advice quit your job and get a new one one question i have having never worked at an agency is what what do you like about it um i i would love to hear this from listeners who've worked at these kind of design focused agencies because it seems like it would be hard to get satisfaction in lots of small tight deadlines of like we got six weeks to crank out this thing for a movie launch and then we're building this new site for an e-commerce company and uh like fast iterations high pressure it just seems

unsatisfying to me but there's got to be something interesting and exciting about it yeah i don't know um i think some people use it as a stepping stone um like it's not a permanent position for them it's like training maybe yeah like i mean it is a really good way to learn how to ramp up on projects quickly and just crank them out so that's true now there's that um but yeah i don't know i don't personally know any developers who work long term at an agency and the stories that i have heard involve a lot of turnover and even for designers too for that matter maybe it's like boot camp for for designers and developers where you just push really hard and then everything afterwards is easier but i don't know because i've never done it uh have we answered this question

i think so okay what was our answer um i'm trying to think back basically by my boot camp analogy i think there's a few parts like first of all is um try to find more concrete clear ways to express your concerns with the design earlier in such a way that the designers can understand them without having to go through the whole build of the product yeah like lower the cost of building that prototype that shows them your concerns yeah exactly yeah yeah that makes sense um and then the second one is talk to your leadership and see if this is actually the relationship that they want maybe maybe it is maybe it isn't and that'll tell you a lot about what you should expect yeah i think the third one is you want to develop trust with the design team and so you might need

to explicitly sit down and discuss this as a problem and and figure out what their problems are also yeah i think if you do that it might it might unlock some issues that you can resolve that will help make the situation better yeah okay we have answered the question question answered where can people go if they want their questions answered dave they can go to soft skills.audio our home on the web where you can ask a question by clicking on the ask a question button you can fill out as much or as little detail as you want we have been getting inundated with questions actually the last couple of weeks so sorry if you haven't heard from us uh we we're trying to process the backlog but um it's actually a lot so that's a great problem to have and we're super

happy to hear all these crazy awesome questions also follow us on twitter at soft skills eng and tell your friends and we have stickers if you want some just send us your mailing address you can send us like a post office box or something if you don't want us to know where you live which i totally understand and we'll mail them to you we i sent out a batch of uh stickers last week actually and we'd be happy to send you some more and you can put these on your laptop or on your face and um anywhere Yeah, anywhere you want. They're really sticky.

Yeah. They literally stick to things. They stick good. And, you know, you can hand them out to your friends. Maybe you run a meetup and you want to hand them out. That's cool. So just let us know and we'd be happy to send them to you. All right, we'll catch you next week.

Thanks, bye.