Soft Skills Engineering - Episode 451: Un-collaborative architect and who is my boss?

Episode Date: March 10, 2025

In this episode, Dave and Jamison answer these questions: A listener named Scot asks, A new architect was hired at my company 6 months ago. I’m an engineer one rung lower on the hierarchy and have been here for 3.5 years. He hasn’t done much to learn about any of us who have been here for a while, so he is constantly undermining my skills and suggestions and assuming he’s smarter than me. On our most recent project we had a lot of issues due to his design, which departed from our best practices. He’s still acting like he knows best and is getting under my skin. Our company usually hires more collaborative people so I’ve not had to deal with this before. How can I stay calm, professional, and confident in my skills while working with this guy? Who is my boss? No, really. I need answers. I’m a Principal Developer with so many bosses, I’m starting to wonder if this is a multi-level marketing scheme. My team lead gives me work. His boss gives me work. Every project lead crashes into my inbox like the Kool-Aid Man screaming that their thing is the most urgent. My calendar is a cursed artifact, filled with 20+ hours of meetings a week, where I nod knowingly while my soul quietly exits my body. My team lead is a Designer and has no idea what I actually do or the expectations of a Principal Developer, which is convenient, because neither do I. When I asked his boss to help me prioritize, I was told, “It’s all important—just make sure mine is done first, and don’t tell the project leads.” Our product owner wants to be anything but a product owner, and our scrum master is treated like the office secretary, not a blocker remover. Top it off, I’m now being asked to weigh in on architecture decisions for our tech stack while not being invited to architecture meetings and being told to “just figure it out” when I asked how to structure the documents and diagrams they want. So now I’m behind on doing dev work, pretending to be an architect, and the team I’m meant to be mentoring never see me unless they’re in one of the same meetings I’m trapped in. How do I set boundaries and prioritize without causing a nuclear meltdown? Or should I just consult a Magic 8-Ball and let fate decide? Because honestly, I’m one email away from faking my own disappearance and leaving an out-of-office message that says, “No.”

it takes more than immediately thinking you've been fired when you get forced signed out of your google account to be a great engineer this is soft skills engineering episode 451 i'm your i think i've been fired i just got logged out of google you're fired from the podcast you're logged out of your brain i'm your host dave smith I'm your host, Jameson Daines. Soft Skills Engineering is a weekly advice podcast for people who need to cope with waking up every morning and wondering if you've been fired multiple times because of weird software glitches or session timeouts. It happened to me this morning, literally the same thing, getting force signed out. And every time it happens, I do have this moment of, wait a minute, will I be able to log back in?

It literally happened to me right before we started recording. My Gmail was like, hey, just want to make sure it's you. I think this is universal because we talked about it in the engineering team meeting and everyone else was like, yep, I do the same thing every time that happens. Oh, it's painful. Google needs to add a little banner that's like, hey, this doesn't mean you've been fired. That would actually make it worse, I think. Yeah.

It doesn't mean for sure that you've been fired because it doesn't guarantee you haven't been fired. This banner may or may not indicate you've been fired. type in your password to find out you know how they have warrant canaries are you familiar with that oh yes like once you've been subpoenaed by the government you like stop doing something yeah like you're not allowed to announce we have been subpoenaed but you can have a page up that says we have never been subpoenaed and then you just take it down when you have yeah and that's people know so they could have something like that like a fired canary that just means when

payday comes around it doesn't show up in your bank account that's usually like the the main indication yeah yeah that's that's fair i guess that's not the canary that's when you actually die the canary is supposed to die before you so you're the canary yeah something else then i guess i guess i don't know should i thank your patrons i was hoping you would all right thank you to these folks who contribute at the admirable level that we shout them out every single week thank you to noah labhart unsalted meow mix is morally objectionable j-ro do you really love us or are we just means to a yacht yes can we do both yeah why not both alexander kuznetsov chris morton nick molyneux michael young.dev attribute error none type object has no attribute

to string javier gonzalez chewy ted timbrel i quit my job but it's 2025 oh god what have i done alexa alexa alexa turn off all the lights become a senior engineer.com is a newsletter you should read unsalted french fries are morally objectionable generating side projects with ai so jameson notices my resume dan from drone to play chase w norton never is not just a crater on mars i like chicken i like liver myomics myomics please deliver trash panda get status kyle boss kensi dodds hold on a second i have to sneeze nevar is not just a planet in the vulcan system jenny kim's a sarcastic parrot helicone.ai best observability tool for ai red panda is best panda java is just discounted c-sharp with worse documentation jonathan king is an eye beautiful

function on the user documentation a whole bunch of stuff i can't pronounce that looks vaguely this is like polish i don't know w super williamangel.net has cookies please accept all cookies we process your data in the united states to opt out go to oogala boogala braden canes john grant britney ellick joe grossberg every monday when i hear soft skills engineering i think i'm going to change my username for the next week then all of a sudden it cody sale okay i i have decoded the unpronounceable thing what is it it is indeed polish and it's a okay a polish tongue twister okay thanks a lot well it's also an english tongue twister because it twisted my tongue it's a it's the name of a town in poland followed by

a famously hard to pronounce bug it's a beetle uh followed by the sound that a buzzing sound followed by a word that means in the reeds we're gonna have to practice this one we'll get back to you next week hopefully we're better so like in the town this bug that's hard to pronounce buzzes in the reeds yeah exactly kind of like a she sells seashells by the seashore yeah exactly well well said jameson impressive impromptu tongue twisting i was practicing with my children oh i crushed them in the tongue twister contest they can't even say easy sentences i'm impressed that i recognized this was polish yeah how did you do that i don't know i just vibes polish vibes yep all right okay dave do you want to read our first question yeah this comes from a listener

named scott who says a new architect was hired at my company six months ago i'm an engineer one rung lower on the hierarchy and have been here for 3.5 years he hasn't done much to learn about any of us who have been here for a while so he is constantly undermining my skills and my suggestions and assuming he's smarter than me on our most recent project we had a lot of issues due to his design which departed from our best practices he's still acting like he knows best and is getting under my skin our company usually hires more collaborative people so i've not had to deal with this before how can i stay calm professional and confident in my skills while working with this guy oh are you getting punched in the gut by this question just by memory i had

a boss who was like this once who just rolled in came in hot uh-huh just joined the team i think felt a lot of pressure to make an impact and kind of like show they were qualified and and could could handle it but the the way they did it was by acting a lot like this just not inquiring not trying to understand how anything worked or why anything was the way it is just rolling up and saying it should be like this and and sometimes it already was like that and they didn't know or sometimes that's they're actually really good reasons why it wasn't like that and they they did not care to find out it was rough i ended up quitting that job influenced by this person yeah partially i think our relationship improved over time and they kind of relaxed a little bit

as they joined and and came up to speed more but it was at one point the worst professional relationship i've ever had with a boss oh but it's been trumped by something else is that what you're saying no i i mean i think it was still the peak it just it just got better than its worst yeah if that makes sense yeah so i can i can feel this pain i also have been maybe i've been this person i have felt shackled by the best practices of an existing code base or team or or process and felt like they were not up for debate as much as I thought they should have been or they weren't carrying their weight, right?

Like, yeah, I get it. There's a reason why you did this. I think it's wrong. It can be hard to have that discussion as well. But I would like to think I was a lot more intellectually curious than this person is about why things were the way they were and also more respectful of the skills and knowledge of the people around me.

this sucks one way you might temper this kind of tendency to come in and take charge is to adopt a curious mindset like i'm gonna guess jameson you are more of a question asker and less of a dictator i hope so i would like to be yeah i'd like to think of myself that way i guess ask some of my co-workers and then you'll find out the real answer or maybe you're a socratic dictator where you dominate people by asking hard questions yeah wasn't he ripped too or was that plato Socrates I don't know yeah one of these one of these either Plato or Socrates was like famously very very strong and would just like wrestle people all the time and I'm that guy I'm whichever one was ripped I'm the ripped Greek philosopher not the soft one yeah I will I will win this

argument and then arm wrestle you until you admit that I won the argument I have some suggestions the more specific you can be about questions and critiques with the actual design artifacts i think the easier this will be because i think it's pretty hard to roll up to this person and say hey i feel like you don't respect my knowledge and talents and consistently assume that i don't know what i'm doing like that's a hard conversation to have especially if you're not getting along super well and if you say that that'll only make them respect you less yeah i think yeah i think it it could yeah they might say well well yeah you don't know what you're doing i mean obviously i have correctly identified that you are dumb and bad at your job but i think it's a lot easier to

point out flaws in a design and hopefully this person is at least open to debating the specifics so if they're an architect i think part of their role should be to to help produce designs but then give feedback or get feedback on those designs especially if they're new to the company like they can't possibly assume they know everything about the legacy systems around them that this will interact with and stuff so oh well the good news is if there's a lot of issues with their design you can just publicly undermine them by criticizing them in front of everyone else loudly viciously yeah nothing nothing solves problems like a good i told you so hopefully they're i mean maybe it's too late you're already in the implementation phase

even then it's not too late i guess but if you're still in the period of time where they are presenting here's how i think we should solve this problem you should be able to point out specific issues with it that are not that is not how we have done it in the past it's departed from our best practices yeah that's that's not a strong argument yeah we don't do it this way it's not it's not a strong argument right it will go so much faster if we don't have to rebuild a logging framework because we already have it built into this tech stack that is a stronger argument then we don't write rust here or whatever yeah we don't like tabs yeah so the more specific arguments you can make about changes that need to be made to the design the better and also the more collaborative

you can be around this the better like if if you can convince them you would like to make this design successful and the project successful you are not here to snipe at them for having ideas that don't follow existing best practices you are trying to help avoid pitfalls and make sure the project is successful i think that's that's a lot more effective exactly the way i would say that which I love, it's a great idea, is state your intentions. If you have a disagreement with someone about an approach, make sure they know why you're raising that disagreement. Because even though I was joking earlier when I said you should undermine them publicly, some people actually would do that. And their intention is to undermine you. And even if no

one on your team would do that, this person might worry that you are doing that. And so say it. Say look, the tenet that I'm adopting when I offer the following idea is that we favor high performance or low latency over development speed in this case. And if you agree with that, I would propose this. Yeah. I think that's a theme we've hit on for the last little while on the podcast is you can just say what you want. And sometimes it doesn't have to be this subtle game of, I don't know, incepting ideas into people. You can just say, hey, I would like to make this design great. I would like to make you successful. And I would like to collaborate on that. I don't want to just attack you or undermine our relationship. I'm not doing it just to score

points or anything. I think this could be better if we adopt these changes. Yeah, exactly. Now, Now, the underlying principle at play here, I believe, is you have someone who has beliefs about you. And those beliefs are manifesting themselves in the form of actions that you perceive one way. So in this case, you believe that this person thinks they're smarter than you and undermines your suggestions. What experiences have given that person this belief? That's a question you really need to ask yourself. That's a reality that you have to acknowledge. have you done anything to give this person that belief then the answer might be yes but it might also be no it could very well be that this person just carries a complex of like look i was brought

in as the what do we say here architect for this team and it is my job to dictate the architecture for this project and so i have to assume that i am right and that that may be what that may be the mindset they're operating in here that's not the mindset i tend to i like to operating because i don't think you get the best results that way but that could very well be what's happening here yeah so if that's the case there's not really anything you can do this is a strongly held belief about their success in this job yeah and then then the question isn't so much like how do you change their mind is is how do you work around that it does suck to work with someone who is not collaborative if you value collaboration and it it can kind of like poison the vibes of the whole

team i guess is how i put it if you have a team of collaborative people and then you have one person who thinks they're smarter than everybody else especially if they're high on the org chart yeah it's not like the rest of the team remains very collaborative and then yeah yeah you sort of work around this person it just feels bad for for everybody yeah now i do have a tactical approach that you could take here that would help which is that you can change the way that you present information to this person i'm reading a little bit between the lines in the question here It seems like the way you're probably getting undermined is that you are presenting information to this person in an environment where other people are watching.

And then this person is going, no, I don't like that idea. And it's like, oh, crap, I've been undermined. But what if instead, when you've got ideas, bring them to this person privately and build a little like alliance with this person and say, hey, I want to review some ideas with you. I respect your opinion. I want to see if we can, you know, get to a good outcome here. I just have some questions. Work through it with the person. Understand what they want. Negotiate

in private. Well, negotiate is not the right word, but discuss in private. Come to a good solution together where this person is not on stage in front of the rest of the team. Then when you bring your idea forward with a bigger audience, with a team and this person in the room, now they've got that backstory where they've got, oh yeah, I helped with this idea. This is part mine. you know and i will i will support it and i will make sure that everyone else knows that i support it and so i think that little private conversation beforehand will go a long way to helping you not feel undermined anymore yeah i could see that working i could also see if you're used to working with very collaborative

people and this person is not collaborative at all you might be engaging with them the way you engage with collaborative people where you kind of like you're kind of playing with ideas together you're like well what do you what about this thing maybe i haven't thought it through very well and and like i don't know we're just exploring like it's it's safe to try out stuff and if this person is not collaborative it might mean that you need to be a little bit more sure of your ideas before you present them to to him so instead of kind of throwing out thoughts i mean this sucks because it i think it makes the work worse and it makes the output worse and it makes you work slower but you you might have to be more persuasive and less collaborative so you've worked on the idea

yourself a little bit more and and kind of built up the case instead of just like what about this thing i was just wondering and then you explore it together i hate that because i love working in that style of of exploring things together and you kind of bounce ideas around and maybe you maybe it's a horrible idea but you learn something from it or or i i hate the feeling of like i have to be right before i talk about that with this person yeah i hate it too but you know that that that approach doesn't scale beyond a certain number of people right yeah and so you know it works one-on-one maybe it works with two or three but beyond that i don't know i hope this person is outrageously good at their job because they are going to cost the team a lot in in uh productivity

and vibes and goodwill so hopefully they're awesome to make up for it but there is there is a cost here that you're seeing yeah definitely well have we answered the question i'm afraid we have all right shall i read our next question yes please do it this is from an anonymous listener who says who is my boss no really i need answers i'm a principal developer with so many bosses i'm starting to wonder if this is a multi-level marketing scheme my team lead gives me work his boss gives me work every project lead crashes into my inbox like the kool-aid man screaming that their thing is the most urgent my calendar is a cursed artifact filled with 20 plus hours of meetings a week where i nod knowingly while my soul quietly exits my body my team lead is a

designer and has no idea what i actually do or the expectations of a principal developer which is convenient because neither do i when i asked his boss to help me prioritize i was told it's all important just make sure mine is done first and don't tell the project leads our product owner wants me wants to be anything but a product owner and our scrum master is treated like the office secretary not a blocker remover to top it off i'm now being asked to weigh in on an architectural decisions for our tech stack while not being invited to architectural meetings and being told to just figure it out when i ask how to structure the documents and diagrams they want so now i'm behind on doing dev work pretending to be an architect and the team i'm meant to be mentoring

never see me unless they're in one of the same meetings i'm trapped in how do i set boundaries and prioritize without causing a nuclear meltdown or should i just consult a magic eight ball and let fate decide because honestly i'm one email away from faking my own disappearance and leaving an out-of-office message that just says no? Oh, what a good question. And also, what a good question. Yes. If you write emails to your team like this,

then I think you're going to be just fine. Your problems will all be solved. Yep. Okay. I think what is happening here is you've risen high enough in the org chart that like the time which you can look at someone and say what do i do is past oh yeah that's that's not the role of a principal engineer yep principal developer you are supposed to be actively shaping

the org not just how you spend your time right and and you're also supposed to be a shared resource for the org as a whole and so the shared resource part seems to be happening in that everyone is dumping all their problems on you expecting you to solve them but you also have to be synthesizing all these inputs into a coherent strategy there's still gonna be some amount of firefighting and bouncing on to like oh no i have to go fix this urgent thing but strategy by going to the meetings on your calendar isn't gonna cut it like you have to be more active here in in shaping what you do and for how i turn to dave that was very well set up uh james thank you i i don't

i thought we were clear that my role here is just to be the laugh track but i i guess i can stretch a little the best part of this question is i know that you are not suffering from title inflation you are indeed in principal engineering territory i can tell by your calendar i can tell by the number of bosses you think you have. And I can tell by the ambiguity that you're having to deal with on a daily basis. This is great. A lot of times people write in and they're like, well, I'm a principal engineer. And I'm like, oh, tell me about the org. It's like, well, there's three of us total. I'm like, okay, well, yeah, you are. You are the principal engineer, but it's not the principal engineer that this person is. So yeah, that's great. I guess what I would do is just ask

for a raise and dry your tears with dollar bills because i think that's where you are yeah this question about i'm being asked away on an architecture decisions and i ask how to structure the diagrams like that's your job your job is to say here's how we structure the diagrams not being invited to the meetings where you discuss it that's a problem you can just say well now i am i'm invited to the meetings i'm coming in case you wanted more meetings on your calendar but like establishing conventions for how you document architectural decisions yep sounds like a thing i would expect a principal engineer to be able to do so it's fine that they don't know because also like you get to just do whatever you want yeah

behind on doing dev work yeah so it sounds like you're expected to also still be writing code and contributing as an ic which kind of makes sense it makes sense but it is hard it is hard to balance with this yeah yeah it's it's it's really hard because often the most important thing you can do to influence an org is not go write some code it's it's like go convince this group of engineers that they need to cut scope on their project or like yeah i don't know establish the strategy for how you measure uptime or i don't know there's there's lots of non-writing code level things that happen at this non-writing code activities that happen at this level And I think the most important thing that's happening at this level is you are facing a prioritization crisis. You are accustomed to being told what's the most important thing to work on. And now no one is going to give you that. And your boss is actually a little myopic who said, just do my stuff first and don't tell anyone that you're doing it that way.

Yeah. But now that you're at this level, it's time for you to look around at the business or the organization you're serving and figure out what is the most impactful, valuable thing you can do to make whatever your key results are happen successfully. And that's going to require you to be a deep thinker on this question and design an algorithm that you can follow to do work scheduling and job prioritization. Put yourself in the mode of a kernel developer and you have many processes with jobs to be done. And how would it do scheduling? You know, how would you allocate your time? Like if you had a blank slate, like zero based budget, this thing, if you had a blank

slate, five day work week, how much time in each week would you allocate to each of these different problems, or each of these different areas, let's say, given the impact that they are likely to have. And in order to do that, you're going to have to pick what are the key results of your organization that you think matter the most. And you're gonna have to put those in order and then allocate time accordingly. And this is great. This is actually really fun, in my opinion. And I think a lot of more junior developers would be like, oh, crap. I just want to be told what to code up. I just like writing code. But that is not the case for a principal engineer. You have increased your scope of responsibility to the point that, yes, writing code is still a fun and important part of your

job, but it's going to be a smaller part of your job. Now you're solving problems with a completely different tool set. You've got people, you've got time, you've got processes, and all of these things you now have the option to design and put into place to try to maximize the chances of success for your organization to hit its results i like that for a lot of reasons i like that you mentioned to achieve the results that the organization wants and and that does feel like a prerequisite here you you need to have a correct understanding of like what the org is trying to do and how they will tell if they did it it's possible that doesn't exist oh yeah if it doesn't good news that's also a principle type of work is is help create that and then repeat it

often enough that it sinks into people's minds say that already exists or say you've created it or i don't know whatever you should be repeating yourself a whole bunch about a lot of things but one of the things you should be repeating yourself about is here are my most important priorities here is what i am working on both as an excuse to not do some other things well not an excuse a reason to not do other things yes like i am not going to attend this meeting because i have to do this other thing that i believe is a higher priority and as a way to like rally the the the troops to use a metaphor i have no business using yeah it's not just about your individual work part of part of your output is also influencing the actions of other people and if it's the most

important thing for the org you want other people to understand that and to kind of align their work with that also so you also mentioned leaving an out-of-office message that says no that would be a good idea regardless i think that's just cool yeah telling people no is really hard in general and it's also really hard if you're known as like a helpful wise knowledgeable person that gets a lot of stuff done and people have grown used to you saying yes but it is an essential skill for doing other things is is telling people no and sometimes you can tell them no by saying not just no i'm never going to do that but you tell them kind of like where they slot in in the queue yes so great i can get to that after i finish this giant q4 project uh-huh yeah and

that's that's not a no but it it appropriately says like yeah i got to do this other important thing first and if they literally cannot do it without you you have made a call that this other thing is more important and and unless someone else overrules that and says nope nope this other project is more important than i don't know you it's part of your part of your part of your authority as a principal developer is you you also get to say no i'm going to make prioritization decisions that affect me and and trickle down to affect other people that i think are correct i totally agree with that it is tough because every every individual like team that depends on you and wants something from you is going to be convinced that your priorities are wrong.

That like, sure, sure, sure. All the other stuff besides our thing is less important, but our thing actually is more important than the thing that you're doing instead of helping us. Right. Yeah. Because it is important to them, right? Like they're putting on their lens with their priority for the thing they're responsible for. And so it's going to feel more important than anything else, which is why you got to get really good at articulating the tenets that you have chosen to adopt to guide your prioritization algorithm. And if someone wants to debate those tenants power to them right like hey i'm transparent about this like this is why i've chosen to prioritize this over that but that's what they should be debating not just saying please do my

thing because i want you to yeah everybody wants you to do stuff yeah the principle this question is just dripping with the implicit statement that no one is rallying this organization with a clear set of key results that people can prioritize their work around and so what i'm seeing here is an opportunity for you to grow into a person who learns how to organize a team and i don't mean like putting them in an org chart and deciding who reports to whom i mean helping a team know which way they should be pushing and what is the most important thing and this is going to be great it's actually super painful to do this and very uncomfortable but also it's a great great skill that like you want to talk about what's his name andy grove's high leverage work this is it i have

a tactical suggestion. I take no responsibility for any bad outcomes, but I do take responsibility for the good outcomes if good things happen because of this. You mentioned meeting in 20 plus hours of meetings a week. And I feel that I've been at, actually, it's not too bad right now. I'm in a very small company, which is one of the reasons why I'm here is it's easier to control and own your calendar. When I was at Omega Corp, I did have many, many hours of meetings a week. And I regret not doing this more. You can just reset your calendar. You can say, hey, I'm in too many meetings. I'm going to say no to all of the meetings for, I don't know, a week or two. I need that time to really go heads down and focus on this important priority. And that part

can be mostly true and also convenient cover to just get out of it. And then you just add back in stuff that helps serve your priorities. It's easy to feel a sense of obligation to go to a meeting that someone has invited you to. And at giant companies, there's also an incentive to invite a bunch of people to meetings because you don't want to leave anybody out. You don't want to miss any voices. So meeting lists tend to grow. People spend more time in meetings as a whole. And there are useful outcomes that come from that. But one of the outcomes is definitely your calendar just slowly accretes gunk. And if you have to go to each individual person that you have a meeting with and say, hey, I'm not going to meet with you anymore. You specifically, like

director of design in this other org that I'm vaguely affiliated with. That feels bad to all involved. But if you can make it a broader thing and say, hey, it's not about you. I actually love your meeting but uh as part of this i'm getting rid of all meetings for a little bit i mean don't say that part about don't don't be slimy about it but it it it makes it easier to pull this off without having to deal with the awkwardness of saying hey i don't want to meet with you anymore because it's not worth my time i would try that as as part of this kind of prioritization work also yes well have we answered that question i think so this is a fun one to think about it is a fun role i think and it's also a demanding and stressful role yeah but the good news is you

are expected to exercise a lot of autonomy here that's right and there are some problems that are hard to solve because you don't really have that much control but part of the benefit of the role you're in is you actually do have some control over what you do yeah and it's the blessing and the curse the blessing is you have a lot of autonomy the curse is that you might tell people to do things and they just won't. So it is when you're leading people. You're going to have to get accustomed to having your primary resource shift from a computer that does exactly what you say to a group of people that may or may not even be listening when you talk. Yeah. All right. I think we've answered this question.

Good luck. Embrace the ambiguity, embrace the autonomy, and take control. i would recommend that you consider choosing your priorities at your work with the same level of ownership and autonomy that you would choose what you're going to do for the weekend like what do i truly want you know i am in charge if i were totally in charge what would i do you have not described my weekends by the way let's say i i need to become a principal engineer of my weekends give me stuff to think about same with me i know a metaphor maybe fell flat that way that's that's the metaphor for people with zero personal responsibilities besides yourself yeah yeah if you are a single person all right what could people do if they want their own questions

answered if you would like to exert your autonomy and flex your prioritization tenant algorithm muscles go to soft skills the audio and click the ask a question button which we monitor regularly and every time you submit one of those questions an angel gets its wings someday you'll meet them all and they'll all say thank you thank you for these wings hopefully they're not mean

they're not little imps saying haha now we can drop stuff on you from above and buzz around your head thank you, thank you so much for listening we will catch you next week We'll be right back.