Posts Tagged “management”

I’ve been doing more than my fair share of deployments lately.

These deployments aren’t the one-click-then-beer variety you find on Heroku or in some seriously agile shops. These deployments are arduous day-long journeys, caravanning eight unique technologies, traversing multiple connected systems both up- and down-stream. And bad things do live in the water.

Seriously, it has been a lot of hard work and some difficult times reliving past mistakes. So here’s my list of freshened lessons that make big deployments suck less:

1. One group chat and one conference line. Don’t use email for the deployment team. It’s slow. terrible at threading conversations. And, somehow, people always get dropped off the address list – or appended to the cc field 37 times. A dozen individual chats and phone calls are terrible for anything but proving why Europe mothballed the semaphore back in the 19th century.

2. A deploy with fewer people is better. An all-hands-on-deck deploy may sound comforting. In reality. that’s just more people in the way, arguing over the best corrective path, and slowly burning out while standing at the ready. Deploys with fewer people – with clear responsibilities and fully prepared for the tasks of the day – beat mob deploys any day of the week.

3. Have your support people at the ready. Just because your core deploy team is fully briefed and prepared doesn’t mean you have all the expertise you’ll ever need. Know who else you’ll need if the fit hits the shan. Make sure that each member of this auxiliary group is ready to drop in at a phone call’s notice. Collect and distribute the best contact information for that auxiliary group to each member of your core group prior to deploy day.

4. Clear communication channel. Who owns outward communication and in what direction? People who need deploy status updates could include stakeholders, upper management, cooperate support teams, and auxiliary team members. They will not all want or need the same status reports. (Hint: you don’t want to send a 100-line deploy plan every hour to your stakeholders.) You need to decide in advance who owns which channel, the frequency of status updates, and the content of those updates.

5. Clear decision-making. When your app server and the database stop talking the last thing you need is a team that descends into bickering over which server to kick first. A deploy will involve a variety of experts, but there should be a single person in charge who – once all voices have been heard – calls the shots.

6. Clear accountability. The entire deploy team should know who is responsible for what well before the deploy begins. For me, that means one owner for each discrete part of the deploy. This separation may be by system, technology or product subteam – whatever makes sense for the deploy. Finally, only core deploy team members own deploy tasks. Sometimes a non-team-member is responsible for completing a task, but we still want a core deploy team member accountable to see that it gets done.

Comments No Comments »

There is one essential interview question I ask any agile PM or ScrumMaster:

What is your process?

Typically, I then elaborate:

With the average size team, the average size project, and everything else being equal, how would you plan, track and execute the team’s activity? How would you report progress and issues both inward and outward? What activities would you encourage, mandate or ban?

This question begins the one discussion I have learned to have with any candidate who will be responsible for leading projects or teams. The answer can be agile-minded, scrum-heavy, lean-wise or even waterfallish. Typically it will be colored by the candidate’s latest experience. But, as the discussion continues, we will fold in earlier experience, hypothetical situations, and the experience of others. I listen for the candidate’s gut-level approach to planning, execution and tracking. I inquire about the candidate’s management toolbox — the practices adopted and techniques fashioned to get projects done and keep teams whole. I listen for toolsmithing — what will the candidate adjust or invent to keep the whole project healthy, balanced and on track? I look for the signs of management craftsmanship.

Yes, every organization has a process or set of processes that must be followed. And, yes, I want to know that the candidate can adapt to the approaches of others. But what I find in surprisingly short supply are team leads and project managers who — left to their own devices — introduce and tailor healthy process to fit in the place of chaos and broken process.

Comments No Comments »

There are two factors that are almost prerequisite to project failure. These are:

1. The team does not communicate sufficient details on project status and issues.

2. Stakeholders do not pay sufficient attention to project status and issues (or the lack thereof).

This does not mean that a communicative team and responsive stakeholders guarantee success. There are too many other things that can go wrong. But it does buy you time to identify and correct for issues before they become catastrophic. In the worst case, stakeholders can determine that things are going from bad to worse and can chose to cut their loses by abending the project.

Ultimately, a combination of clear team communication and healthy attention from stakeholders is your best hedge against sudden and costly project failure.

Comments 4 Comments »

One thing that makes me happy about my current gig is the managers whom I work alongside.

I’ve been in environments that were not nearly so healthy. One in specific where the egos of my fellow managers were matched only by the thinness of their skins. This made most every conversation painful. Sometimes even when the point of the conversation was to pile heaps of praise on an over-egoed, thin-skinned peer.

Comparing these two local environments (I’m not referring to the larger organizations in which they were embedded) I can clearly see how a bit of humility can completely alter relationships both within a management peer group and up and down its management chain.

When managers have some humility they speak frankly to one another and call each other out on half-baked ideas, even in front of others outside of the peer group. Because of humility, problems and issues are quickly identified, surrounded, and resolved. This is a collective and collaborate activity.

When managers are all ego they cannot deliver or accept feedback from one another. They do battle over whether an issue exists and how to go about solving it. They are focused on their own individual agendas and assume that their peers are similarly self-centered in their motives.

The teams that report to humble managers can go about their duties confident that their manager will hear and respect their ideas and opinions. These teams tend to behave with respect toward other teams.

Ego-driven managers let their teams get into messy battles with other teams then defend their teams in these disputes out of blind ego. Paradoxically, ego-driven managers will whip their own reports if an idea or opinion threatens the manager’s ego.

More humble managers seek to resolve issues within their peer group. They keep their managers informed and escalate as necessary but they try not to bother their managers with petty crap.

Ego-driven managers often cannot resolve issues within their peer group. They escalate to their managers as soon as a potential ego-bruising conversation is in sight. Once multiple levels of management get involved even the smallest of issues can result in the deployment of heavy artillery. Productivity and team morale often become hapless victims.

However, an ego-driven, trans-management cluster-fracas can only happen when the upper managers allow it to happen. In unfortunate fact, I’ve known upper managers who encourage egoistic behavior within their direct reports just so they can step into the firefight and “add value” by sorting out the mess. This is an extreme case. Nonetheless, you can behave like an over-egoed jerk at your workplace only if your manager lets you.

Returning to the larger point, it is a real pleasure to manage among managers with humility.

Comments No Comments »

Thought of the day.

Taken from Tom Foster’s entry on Management and Leadership.

Comments No Comments »

I am repeatedly left stupefied by the number of managers who sit by and let minor staff issues fester into clusterf**ks.

Let’s start with a few examples:

  • A young, rockstar programmer who’s acerbic wit is off-putting to the business and even his own managers.
  • The new guy who – while competent and reliable – doesn’t realize that he needs to take the time to learn the team coding standards
  • The property manager who does her job thoroughly but is in danger of losing two buildings because her communication style is so impersonal.
  • Finally, the dependable technical manager whose avoidance of confrontation keeps him from giving honest feedback to his staff.

These people do not realize there is a problem with their behavior. Either because (1) they, themselves, are not even aware they are doing something incorrect or (2) while they recognize the behavior, they honestly believe it is not causing harm to themselves or others.

Without feedback, each of these individuals will eventually hit a wall. When that happens, everyone will feel the repercussions. The property management firm may lose one or two large buildings. A client could get peeved enough at a snarky-sounding comment to take his software development work somewhere else. Or one of the above people may be fired. And have no illusions here. A firing has significant impacts on a team and even the organization as a whole.

Each of these examples is a staff-development opportunity. (And I really do mean opportunity. This is not just spin.) As managers, we need to get in front of these issues. We need to do the right thing for our teams, the organization, and these individuals. By giving feedback and helping direct reports polish their rough edges, we enable people to contribute and collaborate at the best of their ability.

So don’t simply clean up the new guy’s code without telling him. Talk to him. Acknowledge that there may have been no coding standards at the last two development shops where he worked. Or, at least, no one took the standard that were there seriously. Explain why it’s important. Detail the benefits, to both the organization and the individual. Follow up on progress. Ultimately, develop your staff.

One parting shot to consider. By not giving this feedback to the individuals in question, we are doing them a serious diservice. Specifically, we are impeding their professional growth by not identifying the obstacles they must overcome to take on greater responsibility and further their careers.

Comments 1 Comment »