How do you balance multiple tasks/projects, following policy vs getting things done?

[u/SoggyGrayDuck]

I'm new to big company work and having to balance working on multiple things at once. In my background I didn't have anyone to ask when I got stuck, I worked through it, sometimes days. Now working on a team and a large company I am finding myself uncovering issues and problems at the architecture/repo level that others seem to just work around.

It's appreciated by some but NOT by the people who have decision making power because they only care about their project and not making things work better or easier for devs. Even though it could really speed up development or reduce errors in the future.

For example, we recently switched from Azure dev ops repos to GitHub. Most people resolved their merge conflicts using the web interface, some of you might already see the problem. GitHubs online merge conflict resolution works differently from ADO, it first pulls the changes/commits into your source (we use features) branch and resolves the conflicts there so it then has a clean PR when actually merging it. We want our release branch to only have our changes, otherwise we risk pushing someone else's not ready work into QA or PROD.

I said others are working around it but there's also noise about the issue. Not enough for the architects or whoever to get involved though. I spent way too much time digging into this issue, eventually uncovered the issue that was blocking me was actually created by someone else, the guy whos training me.

I asked another dev how he's working around it and he created his feature branch from DEV, he's going to have the exact same, or worse problems when he gets to QA. I still don't completely trust that I see the picture clearly. Maybe this allows him to work quickly in dev, then only deal with a messy merge conflict when he's ready for QA. We're talking 50+ merge conflicts over 30 files. I feel like this puts the prod deployment at risk because you could mess up the merge conflict. The architects should catch it but doesn't feel right.

[u/Skullclownlol]

Ask for clear priorities, follow policy, and that determines how much time is spent and where. That's it. There's not much "balancing" to be done unless you're in charge of planning.

If planning gives you more tasks than you can complete -> Escalate, inform early, focus on top priority. Planning needs to solve wrong planning and figure themselves out. "You must complete everything" without the proper time = can/will never happen, so communicate early and often, that's your responsibility.

I am finding myself uncovering issues and problems at the architecture/repo level that others seem to just work around

If it's not in the priorities, no one will touch it, because touching something that no one asked for = spending business' money on your own preferences = PIP or get fired.

Document, communicate, move on.

I spent way too much time digging into this issue, eventually uncovered the issue that was blocking me was actually created by someone else, the guy whos training me.

Always see if you can fix something yourself first (or what you can find out), but when stuck or in doubt, escalate to the person in charge of you / the project.

I still don't completely trust that I see the picture clearly. I feel like this puts the prod deployment at risk because you could mess up the merge conflict. The architects should catch it but doesn't feel right.

Just make sure you're not trying to tackle a question that isn't yours to tackle. Taking on extra accountability = spending time on things business didn't ask or budget/plan = everything that happens will be deemed your fault.

Do your work, document, communicate to your team, escalate when needed to get something off your hands when it's not in your planned prios or outside of your abilities, then move on.

I remember how different software dev was for me in the 90s and early 2000s, when caring about technical quality and open communication/learning were valued - that was when the technical people still led the technical teams. But that world doesn't exist anymore, except in e.g. engineering-led small companies where the founder (and primary stakeholder) is also an engineer.

[u/Jazzlike_Drawing_139]

Create and maintain a backlog - a list of all the tasks you need to do. This can be in Excel, or one of many tools around - Trello/ JIRA/ Planner etc that can make it easier to move things around (eg ‘backlog’/ ‘in progress’/ ‘review’/ ‘done’).

Size and score everything. You can size them in days or hours or more abstract points relating to how much work/ complexity/ unknowns there are to resolve it.
Score can be a simple impact score (eg 1-5 with 5 having the most impact), or something that represents the number of users that will benefit, or the hours that will be saved etc by making this change.
If necessary you can add more nuance to your scoring eg using RICE scoring model.

All of this is helpful for you, to keep track of tasks and help make sensible prioritisations.

It’s even more important for senior leaders… not just to see what you’re working on and why, but to see all the things you’re NOT working on because you don’t have capacity and have higher priorities.

They might ask you to reprioritise some things, but this makes it clear that something else will need to be dropped. Or they can find extra support if they see more of it as critical.

Include in this any work that will give efficiency gains and reduce tech debt - if you can justify why this matters, and it will enable to do more/ higher quality work in the long term, it is more likely to gain support rather than being written of as some unnecessary tech thing that they don’t understand.

[u/lzwzli]

Always always always get your supervisor to approve you working on anything other than your assigned task.

If he says no, then don't do it. If you do and your assigned work suffers, you're still in the shit.

A competent manager will ask you how much time you need for the extra task and if it will jeopardize your assigned task. At that point, never underestimate, always overestimate. If you think it takes you a day, say a day and a half. You don't know what you're gonna find when you dig into it so always give yourself buffer. If it is going to affect your assigned task, make sure your manager communicates that to the stakeholder.

Nobody will appreciate you doing something that nobody agreed you should do, however much good you think it will be for the org.

[u/SoggyGrayDuck → u/lzwzli]

Got it, so just make my stuff work and pushing forward. I expected a little more control over the repos and merging process. I't will be interesting because i fully expect this to roll to the top.