October 12, 2020
Take it. Don’t worry if you stumble or make a mistake as you get started. You are the one that decided to take on the hardest role when no one else did. Not everyone will recognize that. But those that do. Will be thankful you had the courage to take that step.
October 11, 2020
Letting someone sit in the lobby. Muting them when they are talking. Grabbing the Screen share session. Forcing people on video because everyone else is. Daily Status updates to channels so people know they are working. Making sure that presence icon is always green. These are the new management power moves that are running the remote world. It’s a petty list that does nothing to help your team work better and more effectively. I don’t need to go through each one to say what the adverse affects are – you can do that for yourself. Remote work, remote leadership, remote
October 10, 2020
There come’s a moment in every team’s lifespan, when they start to drift. They become complacent. They go onto auto-pilot. They start going through the motions. What they build is definitely not what the customer asked for. In short, they drift. Everyone knows how to “wake up” your team, fix the drift, get them back on track and figure out what’s going on (if not, there is a way to fix that). Identifying it before it becomes too late is another task altogether that can be harder for managers, especially new managers to figure out. Some early warning signs include;
October 5, 2020
When you had a problem in the office, you’d walk by that person’s desk, sit down, have a chat with them and get the problem resolved. If the issue was raised in the morning (i.e., a delayed project), you’d schedule something for early afternoon to sit down and figure things out. If you passed them in the hall you might stop, have a quick 5 min chat and get things resolved. All of these involved physical cues from working on-site with your team, side-by-side, elbow to elbow – crammed into cubicles that were too small (and we all complained about).
October 4, 2020
Ask any developer how you sort bugs and they might reply P1/S1 or S1/P1. Priority – the impact to the owner’s of the software Severity – the technical impact to the software Both are critical factors in identifying how bugs are logged. Lately, I’ve taken to updating these definitions to apply to other areas of a project that I might be working on. Priority – impact to the owner Severity – impact to the system that we are working on When we talk about the system it could be the process, the software, the team, whatever, but the question remains
