Given that you have no idea right now how long you may need to stay in this job, this answer is to suggest what you could do to improve things while you're still in this position. (There's a lot - you may need to pick and choose your battles carefully.)
- Communication silos from the team level all the way up the ladder. Communication with other teams only happens through my boss, his boss, or through formal tickets. Based on my access to Teams, it's as if my team were the only one in the whole company, as the company doesn't have any general channels. The opportunities to collaborate and socialize outside my team seem far and few in between.
While obviously not something you can control, you and your team should be able to put in suggestions about improving collaboration with other teams. When suggesting improvements it's always helpful to record details of specific incidents where slow communication or lack of collaboration has caused a material and measurable impact on the organisation as well as what your team delivers, for example:
- Work item blocked by lack of communication leading to a deadline being missed.
- Miscommunication or missing detail leading to the wrong thing being delivered.
- Time (money) lost due to work being done with missing or incorrect information.
- Negative customer satisfaction due to communication delays
In all of these cases, include things like dates, how long the delays are, what specific impact these had to the business/project/customer, how much time was lost, what remediation needed to happen. The goal here is not to throw anybody under the bus but to highlight real problems within the company, and the need as well as potential benefits from improvement.
You could make some suggestions to management about ways to make the organisation more efficient when it comes to the projects and features being worked on, for example:
- Daily catch-up meeting between the team leaders for information/issues which affect multiple teams
- Scheduled regular catch-ups between people working on the same feature or "slice" of the product. (e.g. a daily 'standup' with a project/feature focus rather than department/team focus, to include the Business Analyst, Tester, Developer).
- Communal Teams/Slack channels for discussing issues and alerting others outside of the team to things which will affect them.
- Shared access to the team's backlog tool/space for tracking questions/issues on specific work items.
- Centralised system for knowledge-sharing across the business (e.g. StackOverflow for Teams, Confluence, SharePoint, GitHub Wiki, etc.)
Try to be inclusive of your co-workers as far as possible because this affects them too - invite them to make suggestions about improvements and/or examples where they've encountered the same issues.
- The product I develop for is built on an exceedingly complex in-house platform that was not designed for our purposes. Build and testing times can exceed an hour even for simple tests. Public cloud budget limits are routinely hit. Most of the code is undocumented or in broken English. In short, development is frustrating.
Entire books exist on how to work in such an environment (Get used to it -- working with technical debt and legacy code is a core part of being a software engineer). I'd highly recommend reading Michael Feathers' Working Effectively in Legacy Code. If it doesn't help you in your current job, it'll help you in your next one.
A few ideas of things you could look at:
- When working in a particular area of the code, look for opportunities to improve its automated tests.
- Start a backlog of technical debt items (if there isn't one already) for the technical problems that need fixing -- use this as a starting point to try to make the case for improving the system's maintainability.
- Start an issue log which records each specific incident where someone on your team spent time (Make sure to record how many hours/days!) investigating and fixing problems caused by technical debt (which includes external dependencies and the environment/infrastructure). -- Use this as a way of identifying your greatest risks and "pain points" so that the business can see where time/money is being sunk.
- Investigate the possible improvements and tools which could reduce the amount of time spent on supporting and maintaining the system. (Start on low-hanging-fruit if possible, for example, improved diagnostic logging or better analysis tools, improved failure detection, automatic recovery/failover, automatic notification upon failure. Indeed, a lot of tooling and "DevOps"/automation can lead to quick-wins or open up new opportunities to do things in better ways).
- Capture the bottlenecks where developers lose the most time to try to estimate how many total "man hours" a single developer (or the entire team) loses each week/month due to the technology or development process (includes issues with tooling, broken development/test environments, long build/test run times, long and error-prone manual procedures, etc.)
- Investigate possible improvements that could streamline the development process, again low-hanging fruit if possible (for example, project structure changes to reduce build/test time, any automation or scripting for long/tedious tasks)
- Investigate possible improvements for quality - for example, improved code analysis tooling, workflow/process changes around source control and code review, improved testing/test data, CI/CD improvements, more representative development/test environments.
- The team doesn't seem organized. Meetings are unfruitful; there's tension between the leads and the product team. Tickets are passed back or cloned at the last minute with new requirements. Key details in designs are outdated or left as open questions.
These are issues that management need to be aware of and maybe intervene, but as a team you have the power to talk about them amongst yourselves, look at root causes and suggest (or even implement) improvements.
- Keep a detailed log of problems the team experiences with tickets (Ticket number, date, description of the problem, what impact on the delivery/release) so that you can raise this with management -- leave out details of "who". Report upwards to management as a process problem once there's enough of a trail to clearly illustrate how bad/disruptive these problems are and what effect they're having.
- Suggest that the company agrees a "Definition of Ready" for tickets -- i.e. a checklist of criteria for the ticket to meet before the development team can accept that ticket as 'ready for development'. For example: User story, Acceptance criteria, Wireframe/Mockup, No open questions, etc. This should ideally happen with the Product owner(s), Business Analysts, Developers and Testers so that everybody involved can agree on what a 'good' ticket looks like.
- Also suggest a "Definition of Done" -- i.e. what the development team must do in order to pass a ticket into the 'completed' state (e.g. development complete, tested, peer-reviewed, automated tests written, successful green build, passed QA Testing, build/release number captured, etc.)
- Suggest that the team has regular checkpoints/reviews (e.g. every 2-4 weeks) to capture and discuss the problems that impede the team and use this as a platform for continuous improvement. These reviews should be a chance for the team to talk about tech debt, process problems, recurring blocking issues, and anything else which affects the team that fundamentally isn't working, then to discuss what the team or the company could do to fix the problem, and take actions about fixing the problem or escalating it.
- My manager and other leads are unresponsive, as they're in meetings all day. 1:1s get postponed or canceled frequently.
While you cannot fix this yourself, your senior management can, and should.
Senior Management typically have objectives to identify and make measurable improvements to their department; they are likely to receptive if you present them with easily-measurable and quantifiable feedback on what's going wrong and why.
I'd suggest you keep individual records of the number of times delayed responses have impacted your work, and try to encourage your co-workers to do the same.
Improving a situation like this often requires senior management to be presented with clear data which shows negative/harmful trends affecting the smooth-running of the business.
If you can provide measurable, quantifiable data, then it's far more likely that those at the top will take note and attempt to fix the problem, although success depends on everybody continuing to keep track of whether things are getting better/worse/no change.
- I don't feel like I'm growing in my career or in my technical expertise.
Situations like this can be opportunities to forge your own path to growth; engineering is a discipline about problem solving and while many of the problems you face are not inherently technical, you're clearly in a situation with a lot of problems that need solving, with seemingly nobody else even making the effort to grasp or acknowledge them, let-alone fix them.
With that said, a lot of 'process' problems can be improved with better tooling and more automation. If you can get buy-in from your organisation (basically by convincing them that these problems are real, quantifiable, measurable, backed up by data, costing them real time/money/reputation, and even getting worse over time), then you have a foundation to work from, hopefully look at technical solutions which can start to turn the ship around, and a way to be able to measure any improvements.
The recurring theme with any kind of improvement is that the more measurable data you can gather about a problem, the easier it is (usually) to convince management that these problems are real and worth caring about; then continually measure so that you can demonstrate how your solutions are actually having a (hopefully) positive impact.
There may be a lot of scope to be able to suggest new tools or provide some scripts and other hand-rolled solutions which could improve the way your organisation works -- being the one to identify problems and make suggestions might land you in the position of volunteering to define the solution.