In this episode, Dave and Jamison answer these questions:

1. My team are about 4 months into transitioning from a scrum/kanban way of working to a more traditional scrum/sprint way of working.

   I feel like our scrum master is “weaponising” some of the scrum practices in order to show up weak points and failures in the team, rather than working with the team to ease us through the transition and make gradual improvements.

   In private conversations with me and some other trusted developers (lol jk I clearly shouldn’t be trusted as I’m writing in to Dave and Jamison) the scrum master speaks about how little refined work we have in our back log, and how they are looking forward to “exposing bottle necks” in the team. As they expect this will lead to pressure on our PO and Business Analyst and force them to step up their game.

   Whatever amount of work we bring into a sprint is law, and they forbid more tickets coming onto the board mid sprint (even if all the tickets are done half way through the sprint).

   If one single ticket is on the board they will try to block more tickets moving into ready for Dev as they believe we should all be focusing on getting the highest priority pieces of work into the done column. And they take no notice when I’ve expressed the issue with this too many cooks approach.

   They’re a nice enough person outside of a work context. But in work, it really feels like they’re setting us up to fail (and sort of releshing in it).

   Dissent is rising in the team, and everyone from all sides feels unhappy. Can you recommend any action I could take to prevent the failures that are inbound?

   For context, I am a junior developer working for a large company. Within my department we are split up into “SCRUM” teams made up of around 6 Developers, 2 testers, a scrum master, a Business Analyst and a Product Owner. The senior developers within the team have not taken any action other than to complain in secret about the SMs behaviour.

2. Before the tech recession, I would recommend engineers stay at a job for 12 months before looking for a new job in order to avoid having the stigma of being a job hopper. But with the tech recession enabling employers to be more picky, is 12 months long enough? Or should engineers stay at a job for even longer than 12 months before looking for a new job?

In this episode, Dave and Jamison answer these questions:

1. NK:

   Hi, I am starting a SWE internship at big tech company in a few weeks. Given the current state of the market, getting a return offer has gotten harder. I have a few software internships under my belt at this point but I am looking to excel in this internship. My goal is to get a full time offer with high pay from this internship. What are the soft skills that are specifically important for interns? This is probably applicable to junior engineers as well.

2. Hello Soft Skills, I’m a junior engineer who transitioned from an intern to a full-time role at my company a year ago. I anticipated training in development, but I’m stuck in a low-value automated QA role without proper leadership or team integration. My efforts to improve processes and change teams haven’t been successful, and I’m concerned about being pigeonholed early in my career. I need advice on how to initiate change with limited authority and create a competitive job application despite my limited traditional development experience.

In this episode, Dave and Jamison answer these questions:

1. We are a team of under 10 people who provide technical services to other departments of our organization. We use a tool that is built by my boss to supplement our work but it is crucial for the team to do actual work. The boss maintains it all by themselves and nobody is familiar with its code.

   The boss is going to retire in a year or two, nobody wants to learn the code of that tool and the team can’t do much without the boss as we are more or less just individual contributors writing standalone code and delivering it to other teams who asked for it. Only the boss attends the leadership meetings and the developers are completely unaware of the remaining processes that happen in the background, i.e., communicating with other departments to bring in work, and all that business stuff. I am afraid the team would break apart once the boss retires because nobody knows anything on how our team operates beyond within team level except for the boss. Shall I just plan for the job switch?

2. It’s annual review season! When choosing reviewers, do I a) choose the reviewers that will make me look the best or 2) choose the reviewers who might actually give me actionable feedback?

   If it helps, I am on very good terms with my boss and his boss, as well as most of the C-Suite, and there is no way that I get either a promotion or fired in this review cycle. I have been a top performer in previous review cycles, but I expect that I won’t be reviewed so highly this time around.