All hands on deck
Sometimes something happens that needs the whole team to respond. When possible plan these out and ensure everyone’s there and involved.
Most of the time our work fits into the (insert your normal working hours here). This means we may or may not see the whole team we work with at any given time, and we can reasonably expect to be unavailable when we go home to do things like not work. There are, however, times when we need everyone to be available outside those hours. These situations tend to be big deployments, massive outages and other (thankfully!) non-standard events. While everyone knows they come up, they do frequently cause a lot of friction… after all, who wants to be dragged into the (virtual) office on a Sunday?
I’ve found a number of things help at least easy the pain of these events:
Plan it out in advance
When possible these events should be planned out in advance. This is easier to do on bigger projects where you can predict when major events (like a go-live) occur, but to some extent this can also be performed through risk planning. For example if you know a holiday is coming up and your system may be stressed, have more folks placed on call.
Planning it in advance helps everyone plan for it; now they can not take holiday and they can move other personal things out of the way. Planning it out also helps everyone see it’s an important part of the project/etc. And sets an expectation that its a required action vs. an optional event.
EVERYONE shows up
I usually serve as the project manager, so I’m rarely the one actually performing the go-live. This means my presence isn’t as critical as the developers, but I still make a point of being in the room as things unfold. This extends beyond my own personal sense of ownership of the project and into a sense of camaraderie. If everyone knows that everyone else will be there during crunch time, it’s more likely they’ll show up. Experiencing this stressful event together will help the team bond, and make it feel more like, well, a team.
Loosen protocol
Depending on the office culture this may or may not be a good tip, but loosening protocol (e.g. dress codes, eating at your desk, whatever) during these events helps to ease folks into it. It also helps deflate arguments about people being available as they can be more comfortable… or at the very least makes it more palatable (well at least I can wear my jeans).
Clearly define what needs doing
This goes with the “plan it in advance”, but you should (ideally) have a plan in place for what needs to happen during crunch time. This helps reinforce the “this is important” aspect of things, but also signals to your team that they aren’t going to be wasting their time. It also gives you a finish line to point at and keep driving towards.
Priority Zeros - Everyone’s got ‘em (sometimes several)
Finding a way to prioritize work is critical to success. The one approach that should NEVER be taken is to have the tech teams determining the priority… they’ll almost always get it “wrong” and end up agitating partner teams.
Priority Zeros. Everyone's got one, something dozens (which I always find amusing - how can there be multiple highest priority items?…). These items are the highest priority and most important item for any given group or individual. It's a great thing when a team can truly determine what these are as it allows them to direct work. It's a much less great thing when tech teams are given them without a structure in place the help manage them.
Collision alert!
Once you get to the point where you're regularly identifying P0s you’ll (hopefully!) start looking at how to accomplish them. This generally involves passing parts of the ask to other teams to do the work. Depending on the ask this can span large swaths of the company, or just a small targeted group. Given today’s information-rich environment, tech teams are almost always impacted by these asks. While it’s great that tech is thought of as being needed, a very serious challenge begins to emerge - What happens when tech gets a P0 from Finance and one from HR?
In an ideal world this balancing has already been taken into account where a designated person or group determines the actual priority (Finance then HR, or use some semi-objective ranking system, e.g. which one costs the most to implement). I won’t delve too deeply into what that process looks like, but this group should be ordained by the business to make, and defend, those decisions so the tech teams can focus on execution. This approach is great since it removes any pressure on tech to determine which should be done first and provides clear guidance on what order stuff should be completed in. It also helps ensure the business know’s what tech is up to, and when they are doing any given item (other very common challenges with prioritization).
More frequently, however, the decision is dropped on tech, and tech has to figure it out.
This is a terrible idea.
I dunno, that one first?
It's terrible because tech doesn't know which item is more important to the business. If we’re lucky we can sometimes make an educated guess, but this is very much a mystical art from the tech standpoint as is it very rarely objectively clear cut. For a vast oversimplification (many tech projects span months if not years), is it more important that an alert goes out from Legal or a finance report has a column added? Tech can guess (I’d hazard towards Legal on this one?), but at the end of the day it’s not your tech team’s job to determine priority of this type of work - it’s IT’s job to execute on the decision that is made and to ensure that it is executed properly.
In addition to potentially the “wrong'“ item being worked on, it’s terrible because no matter what order tech completes the items in it will be 'wrong’ to one customer or the other. If we go with the “Legal” option above its highly likely that Finance will come back at us more than a bit unhappy. Tech can try to justify why they chose a specific course of action, but at the very least this takes away from time better spent working on the item. Even if there is some justification Tech uses, it’s likely that Finance will disagree with the criteria (e.g. why are alerts weighted more than reports?). This ties back to having an ordained group or individual that all groups trust - it helps eliminate frustration down the road.
But we don’t have that…
There’s a variety of reasons why that ordained group or individual doesn’t exist yet. Maybe your company cannot afford to dedicate a single headcount to it (yes, this is a full time job). Maybe your company wants to, but has higher priorities (a bit ironic that). Regardless of the reason there are some steps you can take to help bridge the gap / mitigate the damage. This will require some amount of process / procedure, however, it will help protect your tech teams and avoid frustration from the business.
The intention of this individual is to provide a source of truth for the order of your tech teams work. This requires this person to be familiar with everyone on the tech and the business side, and have a working relationship. This person also needs to understand how the tech teams operate and what their capabilities are. A person like this may already exist on your team (or on the business side). This may be a finance expert who wants to learn more about tech, or a techie who wants to get a better feeling for how the business operates.
You’ll also need to get leadership buy-off on this stop-gap. Figure out who the decision makers are on the business and tech side and grab some time with them. Explain you want to dedicate X amount of someone’s time to helping prioritize and order tasks (with input from both teams). It shouldn’t be too hard to get buy in as they are likely feeling the pain of not having this role, but you can always point out the time/heartache savings by having an objective to-do list. You’ll also need to setup some kind of regular update/meeting with this group so they feel comfortable trusting your designated individual, but this is good since it will help keep you honest and get you feedback.
It is definitely an iterative process, but once trust is developed and the wheels start turning more easily marked improvements in efficiency and grey-hair will start to show up.
Same team!
It’s REALLY easy to fall into the trap of blaming the business or the tech team for a failing project or take out frustration on them. At the end of the day the most important bit to remember is everyone is on the same team. Tech teams don’t have anything to do without the business (except watch server lights flicker) and the business will have trouble improving without tech (there’s a limit to gSheets). The challenge is in bridging the gap, in helping the tech side understand the business’s priorities, and the business understand the tech teams capabilities. Providing a single point of truth for what should be worked on is a huge step in that direction, and one that you can start taking without breaking the bank.
"This other place I worked at did it this way…" ~ Some Executive
Tech teams need to be brought problems to solve, not solutions to implement. Frequently business partners only present their ideas for solutions, which, at best, will steal time from actual problem solving, and at worst cause problems down the road.
This is one of the phrases I dread hearing the most, mainly because it usually ends in “... so I’ve already told everyone we can do it this way” (or something scarily similar). This phrase definitely falls into the bucket of “partners telling us solutions” (which has it own dangers), however, for me this one is a little bit more insidious…
A Game of Telephone
Generally I don’t hear this phrase first hand. Instead, I’m (un)fortunate enough to hear it second, third or fourth hand. It tends to originate from someone higher-up in the org chart, generally a VP, Senior Director or the like. It also tends to originate from a place with good intentions. After all, this person and their team is faced with a big challenge, so why not use something they KNOW has worked before?
How it plays out (in Robs super-oversimplified world)
Why it’s scary
This is scary since where ever we are now, we ARE NOT at the same place this worked for them in the past. We’ve also entirely skipped the part where we identify the problem. Even if the business is identical and we make the same product/service, the way our systems are setup will differ in some fashion. Generally we’re not in the exact same industry, making the differences even greater. Further, the individual who puts this idea forward likely does not understand the specifics of what was done, only the end product (it’s seldom a Director or higher I meet who truely cares to learn the technical specifics). So even if the solution worked exactly as remembered, they do not fully understand the pretzels their tech teams had to wrap themselves into in order to deliver.
How it should play out (in Robs super over-simplified world)
Getting from scary to supportive
Technical teams (whether it be IT, legal, communications, etc) are the experts in solving problems, so we get very concerned when instead we’re fed solutions. The best way to improve this relationship is, well, to improve the relationship. I personally spend a great deal of time working with my partner teams and sharing the basic concepts / patterns/ processes that my team uses. This helps demystify tech (that said a lot of it is still magic to me) for my partners, and, more importantly, helps build trust. This is needed for those times I have to tell them that what their VP said may have worked somewhere else, but it may not work here.
In the end it all boils down to the strength of relationships with partner teams. These scary phrases will continue to come up, but, they should become less and less scary as time goes on and more and more folks know to trust their tech.