Matt Schmitz/ March 7, 2017

Too often, it seems like a common component of office culture is complaining about the issues. “Why do we always do things this way? It’s not the right or best way.” Even when things are running smoothly to most, there will always be someone who believes that things are not being done right. Occasionally you might get lucky and someone will suggest a better option. However, in my experience many of those people only offer the better option as a suggestion, then complain when nothing changes. So let’s take a look at how not to fall into that trap.

1. Identify the problem – This can be the both the easy part and the hard part. For example, let’s take a recent example at my job: Poor coordination across teams for project work. Awesome, we have identified the problem, right? Well, not quite – that may be a high-level summary of the problem, but why is there poor coordination? Maybe the teams aren’t meeting often enough with each other, or maybe those meetings aren’t structured in an effective way.

2. Identify the solution – So it’s easy for anyone to say “I FOUND A PROBLEM”, yet it’s more difficult to come up with a reasonable and effective solution to that problem. Sit back and evaluate the problem, but make sure you consider the perceptive of both sides. Maybe Team A works better if they have all of the information up front, so they can design a proper solution – yet Team B likes to work as they go, and tackle things as they come up. In this case, we probably won’t get very far in asking Team B to schedule architectural/design meetings before starting a project, will we?

3. Propose the solution – This part is important, because we don’t want to start making changes without anyone understanding what or why we are doing it. If changes come out of no where, people are more likely to reject them. So maybe we sit down with Team A and Team B and explain our solution: We will hold a quick, high-level design meeting at the beginning of a project – but Team B will be responsible for trying to notify Team A  as soon as they identify a new requirement, and Team A will be responsible for identifying when those new requirements warrant a bigger meeting to gather requirements/details.

4. Make the change – This is probably going to be the most difficult step. If you want the change to happen, you cannot stand back and hope that someone else does it. You have to lead the change. For example, if you are on Team A and you propose this idea, then you must hold Team B accountable to sitting down for a requirements-gathering meeting when you think one is needed. Give it a good effort, because if other teammates see you working hard to make working-life better for everyone then they will be more likely to join in.

5. Re-evaluate and refine – No one is perfect, and no idea will ever be absolutely perfect on the first try. So give it a while, then make sure you sit down and take a look at how this change has impacted everything. Has Team A been more productive, since they can get requirements earlier in the process? Has Team B become less productive due to the increase of meetings? You might get lucky and have a fairly smooth transition into a better working environment – but chances are good that the overall change might still need some tweaks. Don’t let yourself fall into the ‘set it and forget it’ mentality – getting better means constant improvement.

This might seem like a lot of work just to make a simple change, but it doesn’t really have to be. As a real-life example, I recently worked with another team who was starting a new project to install an entirely new application. They began by submitting individual tickets to the network team with bits and pieces of what network changes they believed their project would need. Once I realized this was happening, I asked the person leading the project if they had 30-minutes to sit down and talk that afternoon. It was a very quick meeting where I asked about the application they were installing, what it did, how it was intended to be used, and what other applications/systems they believed it would need access to. I also provided a little insight into why this mattered to me from a network design perspective. From that I had enough of an understanding of their project to put together an effective design from the network side, which makes both of our lives easier – because we don’t have to piecemeal it together now then realize later that it wasn’t the ideal configuration. After that meeting, the project lead said “Man, I always wished we had a lot more meetings like this – this was really helpful”.

That is the difference between wanting change and driving change. The bottom line is: If you want to inspire positive change – You have to be the catalyst.

I’m sure we have all identified areas of improvement with our workplace. Have you ever been the one to drive change? Leave a comment below, and tell me your story!

About Matt Schmitz

Herding packets since 2007. Perpetually trying to automate myself out of a job. I believe that all problems can be solved by implementing more IPv6. Disclaimer: All opinions posted here are my own, and do not represent any vendor or current/former employer.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.