Keeping a software team going, engaged, and motivated doesn’t take someone cheering to hype up the team. This would work about as well as cheering for someone working on a crossword puzzle, in fact it would have the opposite intended impact. Encouraging and motivating a cognitive basis team takes a different approach. Many seemingly innocuous actions can negatively impact a team, instead of focusing on what not to do, I wanted to go over what I feel are good things to do.

Many of these are a blog post within theirselves, so to keep this down in size, I’ll try and make it quick. But each topic could be expanded upon.

Working Agreements

Teams need to have their own working agreements. I often find employees not thinking of doing this enough, and is something vendors/contractors do more often. They need to establish working agreements because they need this as a place of understanding and setting expectations. I find discussions, arguments, and some conflicts can be resolved long before emotions are at play by establishing proper working agreements. These can be used as conventions, or “rails”, for the team to follow.

You can easily find templates for establishing working agreements online, having the team spell out what their own beliefs, values, and rules of the game are important for establishing self-autonomy.

Limit WIP

Find ways to limit what the team has in progress, having many things to keep track of can exhaust a team. There are two ways to look at WIP, one is a total number of cards in play and the other is how many epics, or common themes, are in play. Looking at the total number of cards and finding ways to limit those amounts is purely a team and Tech Leadership decision. Limiting the amount of epics at play normally brings in the Product Owner to the discussion as well.

Make the Priority Clear

Many teams really want to limit what they have in progress and be able to deliver things, but as they are asked for more and more, then they will often have a hard time saying no. Making the priority clear and describing how their priority relates to others is also beneficial. As their Engineering Manager or Director, they will find it comforting to know the clarity of what is happening and find it easier to say no to those things.

Personnel Problems

Definitely not one a lot of folks are comfortable addressing or bringing up. But this is a killer if left alone. You don’t have to snoop around and dig up dirt on specific people, just make yourself available, and obviously listen to the team members during 1-on-1’s. A big lesson learned for me was finding out what the Corporate Policy is for handling under performing team members. I waited until after I tried everything I could during 1-on1’s with no improvement to then engage HR (the corporate policy). It took much more time than I expected to get the ball moving and all the while the team was really upset that the behavior of the individual was being tolerated.

Listen for Problems

There could be numerous problems on this and I won’t be able to touch upon all of them. But as noted previously, listen during 1-on-1’s, what are people complaining about? People often aren’t negative the whole entire time, but listen to things they want. I’ve seen developers brighten up when they find out they can expense their cell phone or home internet. Their prior supervisors never brought it to their attention, with you bringing these kind of items to their attention shows you have their back, and you having their back is one of the best things you can show a team.

Again though, listen to them. If they have ideas they feel are not being heard. Then schedule white board sessions with them to hash out their idea. Work together with them on putting together an article, documentation, or slides to show others. Take the initiative and schedule the meeting with other peers or even better your boss.

One big key here is if they aren’t saying much, or if they are saying everything is fine and nothing is wrong. No room for improvement. Then highly likely you, their leader or boss, is their problem. I’ve had team members talk to me about their problems with their boss (who didn’t report to me and I didn’t report to them). Come to find out their boss just didn’t listen to them and didn’t ask questions well enough. The team didn’t trust them, so kept information from their direct supervisor.

Some smaller items to consider that play a big role for developers:

• Are they physically too close to one another?
• Too far a part?
• Bad chairs? I was shocked at one company I visited where their labs had broken chairs, some even had no back because the back had broken off.
• Need a new keyboard or mouse? Ask them for what their favorite keyboard and mouse are. If it is different than what they have in the office, then working on getting those purchased.
• Is their work laptop or VM powerful enough? One DBA I worked with had a grossly under powered VM he has required to use, it would take 5-10 seconds for many key strokes to show on the screen. I got him one that responded close to a native desktop. Needless to say, he was excited to have it.
• Does CyberSecurity have anti-virus that is slowing them down (have those conversations with others, see what options exist)

Mental Exhaustion

Is the team making progress at all? Do they feel stuck and slowed by something technical? Are they troubleshooting an issue and having issues making progress? Bringing in someone from the outside, a short-term contractor, could be a wonderful shot in the arm. Teams when stuck with a troubling technical problem can be mentally exhausted or even scared to make a wrong decision (after all, many programmers are Stable).

This can also be tied to high WIP as well, if there are many different epics/themes at play, then the team could be under decision fatigue or context switching fatigue.

Anchors/Engines

Technical Debt is commonly discussed around software engineering teams, so be sure the team has a strategic plan, rack and stack, list of tech debt items they would like. Engineers love looking for better and newer ways to do things, and this can cause endless conversations about what folks want to do with the project. So yet again pull the team again and have a white board session. At a high level, list out all the things they would like to do. This isn’t a feature or product view, this is more technical. Make sure everyone is heard. Talk about the value each suggested item could bring, what all would it impact, any chance for a piece meal approach, time box a POC …etc. Get them listed. Then ask the team to start ranking them. Have the team acknowledge “This is our plan, we all know we want to do #17 on the list, but until we get 16 other things done, then there is no sense talking about it. Let’s get our focus on the top 1 or 2, let’s all get behind it and knock it out of the park”.

Another exercise to perform with the team is identifying Anchors and Engines. This could bring to light items leadership is not aware of and bring to light items to use more that are speeding the team up and identify those items you need to mitigate.

Lunch

Maybe this one should be more at the top of the list, this is such an obvious one, but it is typically ignored. There are Foodies all over the place. People love their food. Many others are interested in trying something new. Others enjoy taking their team to their own favorite spot close to the house. Figure out the budget you have for this, ask for more money for team building, and get these on the calendar. Now.

With remote teams this is a bit harder, and normally doesn’t apply. I have seen teams that get along well eat lunch over zoom together, have happy hour, have a “water cooler” online meeting …etc. Different ways to approach this with remote teams.

Activities or Ceremonies

I sure do hope the team is having their own ceremonies and they are running it themselves instead of the boss. Do they have dailies? Tech huddles? Pairing or even better yet, Mobbing sessions?

Story Telling

Who is using the app your team is building (or impacted by your app)? Find stories of people using it. Story tell these back to the team, point out how they relate back to the team’s Beliefs, Values, and Rules of the Game.

For many backend applications, the net benefit is often lost on the team on how their work relates back up to a Strategic Objective. Help showing the team this path. Then also show them how the next thing coming up will also have a positive impact. Show them the road where everyone is headed and I’m sure excitement will follow.