Seeking Advice on Navigating Team Communication Challenges
Posted by Dizzy_Conversation92@reddit | ExperiencedDevs | View on Reddit | 14 comments
Hello everyone,
I recently started a position as a software architect, and I am reaching out for some advice on a challenge I am facing. My primary responsibilities involve understanding business requirements and creating high-level technical plans for implementation.
However, I have encountered a significant issue: the project team appears to be quite dysfunctional. Effective communication with key stakeholders, particularly tech leads and software engineers, is crucial for me to draft accurate plans. I need to grasp the existing architecture, its limitations, and the team's engineering capacity to ensure successful project execution.
Unfortunately, I am finding it difficult to get the necessary input from the team. Despite my efforts to reach out directly to engineers, utilize group chats, and communicate through their managers, my requests often go unanswered. As a result, I am accumulating new tasks without being able to make progress on ongoing ones, leaving me feeling unproductive and frustrated.
I have already discussed this situation with my manager, who acknowledges the communication breakdown but has indicated that it's up to me to address the issue. While I am not currently under pressure to deliver results due to these obstacles, I am concerned that this situation could negatively impact my position in the future.
I am genuinely enthusiastic about this role and the work involved, but I find that a lot of my time is spent waiting for the information I need to move forward. In my previous experience as a software engineer and team lead, I never encountered such a dysfunctional environment.
What strategies or approaches can I adopt to improve communication and collaboration within the team? I am eager to find a solution, but I am also considering my options if the situation doesn't improve.
Thank you for your insights!
Crazy-Willingness951@reddit
You may wish to check out "12 Essential Skills for Software Architects" by Dave Hendricksen.
dnult@reddit
Sounds like you need to call a meeting. Electronic communication is fine for short messages, but it's not a good way to work through the details of a plan.
Life-Principle-3771@reddit
So why are you taking no as an answer? I would write down all of the questions that you have and just set up meetings with whoever you need to talk to.
And I know what you can say to this, which is that what happens if people don't show up to these meetings? Very simple you just keep adding meetings and document when people are missing them. After people miss a couple of times start an email thread with their manager, just something like:
"I need to understand x to perform my job. I have been trying to get in contact with person y to help me understand this. I have tried to setup multiple meetings at time/place and time/place, which he/she was not able to attend. I have setup another meeting at time/place, can you ensure that they either meet more or we find a better time to chat". CC all involved parties.
Very simple. If you don't get a response or the person doesn't show just find whoever their skip and and email them with basically the same message, also pointing out that you emailed the manager. Just keep going up the chain until you get what you want. If you have to email the CEO and CC fifteen other people on the email to get someone to talk to you then do that. And just keep doing it until people are responsive to your questions.
Oakw00dy@reddit
I think it's vital for you to figure out what's behind the dysfunction, whether it's resistance to your role or just general lack of organizatinal maturity. That said, I've found "speak now or never" approach useful: Write down your best understanding or plain make up shit, then send en email to those who refuse to communicate stating that "this is my understanding how things work, if you don't agree, speak now or never". If they don't respond, follow up with, "thanks for agreeing with my plan". That way at least you will CYA.
UncleSkippy@reddit
Seconding this but extending it a bit further. If OP has already gone through managers - who aren't doing their jobs and have themselves given up on addressing the issue - then make the effort to reach out to each stakeholder three times. If there is no reply, you get to dictate decisions at that point.
Next, set up a meeting to go over the design/plans. People WILL complain and point out issues. Your only reply to criticisms should be "that is noted. thank you". No snarkiness. No "you should have said that weeks ago". Nothing like that. You have the feedback you wanted originally and can incorporate it. This is an alternative way to gather feedback: disclose your draft plans as if they are your final plans, listen to criticism, and then adapt the plans. This tends to work well because the draft plans provide a framework for the discussion.
Plus, if the team is burned out, this can help reduce pressure on them by not putting something on their plate and forcing immediate attention. In the end though, burned out teams are the result of poor management.
Oakw00dy@reddit
Excellent points!
wwww4all@reddit
Do you not realize that’s why you were hired?
To solve these communications challenges?
Don’t just wait for things to fall into place, you have to actively go and seek out info needed.
If these challenges didn’t exist, the role wouldn’t exist.
Antique-Stand-4920@reddit
This sounds like a possible goals alignment problem. Are your top priorities similar or same to the priorities of the rest of the team? If not, it might be the case that the rest of the team is being held accountable to certain projects that are not yours. This can result in the rest of the team in seeing and treating your projects as a lower priority.
Twerter@reddit
Is the team might be overworked? Can you dig through the code yourself?
Dizzy_Conversation92@reddit (OP)
> Is the team overworked?
I am not certain. There are many complaints from Devs suggesting they are, but I can't confirm if that is really the case.
> Can you dig through the code yourself?
Yes, I can and I am currently doing so. However, it's a vast distributed system with multiple technology stacks, and no single team has a comprehensive understanding of everything at a high level. Developers tend to focus only on their specific areas. Additionally, there is a lack of documentation, and some codebases are very outdated and follow poor practices.
Twerter@reddit
If I'm honest, this just sounds like every job I've ever taken so far. Are things usually different for you?
Dizzy_Conversation92@reddit (OP)
In my former positions things were quite different. As I was directly involved in the development process, which allowed for daily communication with my peers. So even if the stack was shit and there was lack of documentation, people were more approachable.
However, in my current role as an architect, there is a noticeable disconnect. We are more aligned with the business side than with the engineering teams. We don't participate in implementation decisions, retrospectives, or daily stand-ups with the engineering teams. This lack of involvement means I have limited insight into their situation. They could be overworked, dealing with significant technical debt, or perhaps not fully engaged, I just don't know. Unfortunately, I don't see a clear way to bridge this gap.
fhadley@reddit
Not much useful to share here unfortunately but man am I glad I grew into an architect-ish role internally instead of trying to drop in somewhere new and do this work.
I consistently find that a good way of getting folks on your side is finding ways to demonstrate high competence in a low-ego kind of way. It's much easier to do this if you're hands on writing code of course but there are ways to get there at a higher level of abstraction as well.
Getting super familiar with a code base is one way to do so. Other ones are writing tests or if you're willing to be a bit aggressive, every team has long standing known bugs that haven't been fixed for months because of a long laundry list of reasons. Maybe carve out a bit of time to pick up one of these proactively, though again that's quite rather forward and a bit higher stakes to get right with a new team.
You want to figure out how to be as productive as possible, as gently as possible. The more you can influence and steer as opposed to dictate/enforce/command, the better things will go for you.
Sensitive-Ear-3896@reddit
Start with code reviews as a required approved, comment as this doesn’t follow the guidelines set out in document x246 and just see how eager they will be to discuss x246.
They will say x246 is bullshit we never talked about this… and you will say well, I tried but…
Try to make it so their manager misses a deadline or two.
Just remember the only thing most devs care about is their next Mr. The only thing leads/managers care about is the next release, that’s where you gotta meet them