Sometimes the best thing you can do is back off.
What do you do when you've got a problem on your hands?
Sometimes the best thing you can do is back off.
Your employees don't want to be treated like children and they don't want a baby sitter. In the professional realm that I work in, Individuals want to feel empowered through the work they do. Especially in something so ethereal as software development. Occasionally things start to turn south and everyone starts to wonder what is going or went wrong? Often as a result of this downturn really destructive things start to happen as the pressure from upper management starts to bear. Decisions are made that it's time to try something new, something drastic. Perhaps it's a new technology. Perhaps it's a new way to manage your employees. Perhaps it's a new feedback system. In my years as an engineer there are many valuable and ultimately "people" centric things I've come to appreciate. But one of the more important realizations I've come to is that people need to feel trusted. So again, if we are talking about engineers then that trust can manifest in believing and supporting their judgements on a particular technology or architecture decision. Or perhaps letting them drive innovation at the company. One thing imparticular though is terrible at supporting trust and is instead excellent at breaking it down. That is the premise of force-feeding something from the top down. There are several ramifications that come from force-feeding your labor force and the following are just some of them. Morale plummets. People loose their trust in their managers because instead of allowing them to make decisions, decisions are being dictated to them. They are, after all, working professionals, don't their opinions count for something? Indeed, people start to realize that their opinions no longer count and some find other jobs. Some continue to work and instead lose the passion. Others simply checkout mentally and ride it out for as long as they are gainfully employed. I posit that before these drastic measures are taken sometimes the best thing you can do is back off. Why? because you hired your employees for a reason. There is a reason that they do what they do and you do what you do. Exercise their abilities. Be honest about the problems the company faces and ask for their help in fixing them. Make suggestions, but not ultimatums. Trust your employees, if you don't, your product will suffer whether you know it or not.
So that is the "What", now the "why"
First some context. I am an engineer at a mid-sized company not unlike many other companies out there. My company had the good fortune that they grew quickly from a small team to an organization with over 60 developers and a widely loved product. Our company is not exempt from many of the things that plague other companies facing exploding growth and as a result there are some significant technological hurdles that we are facing internally.
Two examples of the wrong way to do it.
Example 1
Our team faces some complex infrastructure to maintain our application. Some would argue that the infrastructure is overly complicated (which it is) and that other new solutions would be better for us in the long run. Trouble is that there is no free lunch and everything has a cost. So in coordination with the previously explained wrong way to go about change, our company has made some decisions from the top down to focus our efforts on a new and hip tool for the job, the one and only NodeJS. Now don't mistake me, I am a front end engineer and as a result of having worked with JavaScript quite a lot, I really like Node. I think that for a lot of teams and for a lot of circumstances Node is the medicine that the doctor ordered. The only problem is, there are some problems with this thinking. First, Node is a somewhat polarizing technology. There are those of us that love it and those of us that hate it. Count yourselves where you see fit. Second, Node is a tool and we all know that tools by themselves don't provide solutions. It's the way in which those tools are used and their result that is important. However, in the spirit of doing it wrong, the management has made decisions about the technology we are going to use (Node), rather than asking/trusting engineers to make that call. As a result I see a lot of division in my workplace. I think that despite the benefits, no technology should be worth the sacrifice of your engineering organization over. None.
Example 2
Another pain point of the company I work for is how we manage our code, that is how do we effectively use VCS. We are on Mercurial (the lesser known and less popular cousin to git) and for the most part it works ok. I am a bigger fan of Git but sometimes you have to let bygones be bygones. Now for the kicker. In discussion on some of the ways that my team can use our vcs, management brought up the idea that they wanted all of our products/projects for our team in one repo. My first reaction was confusion followed shortly by a strong opposition against that decision. Now, for the sake of argument, I will take a step back and try to understand why someone would want to do this. There are some hypothetical yet arguably weak arguments in favor that I will describe: first, everything is in one place. Meaning it is never difficult to find out where team A's code is because it's always in the same place, that one huge repo. Second, everything is in one place. (I know I repeated myself). In this way its easy to onboard a new dev because there is only one place to go. Moreover because of the "one place" argument it could be easy to run a build that does all the projects at once? (I'm kinda grasping at straws here...)
So basically that is the long short of what I could come up with in favor of one-big-giant-repo-of-madness approach.
Now the counter arguments:
Everything is in one place! Arg, this is like the argument that won't die! The reason that I mention it again is that it's actually quite a detriment not to break your code into smaller pieces. To this point, there is no longer relationship between all the pieces of code you own but instead that relationship is tied to you team. It's like the semantic argument we see in html and how using nomenclature like a team name within an organization gives an end user little insight into what the code does. Secondly to this point, it's a commit nightmare. Imagine for a moment that there are several people working on several projects in this single code base. If there are several interleaved commits to several different projects and then one of them has to revert, how much more difficult is it to make that revert? Instead of simply reverting and perhaps throwing away some bad code, you now need to mitigate all the interim code that was committed to those other projects. How much simpler it is if that code were to have been its own repo! The problem is also compounded when you start any sort of branching strategy on those projects by the way. Second major point, repos are cheap! relatively speaking, repos are a cheap commodity. USE THEM. It is so much easier to have your code modular than to have it in one monolithic project. If nothing else, leverage your ignore files so that the same code isn't being watched in other repos and you're golden. Third major point: Builds become difficult. We like to use webhooks and build systems like Jenkins. If you have one big master repo, it becomes a major mess getting those webhooks to actually build what you want vs everything you ever touched.
All that being said, back to the issue at hand. The problem is that management decided that this is what they wanted and from an inferior position, i've had to coalesce.
You're doing it wrong, you need to back off.
So why go through this exercise? Is it to disparage managers in my organization? Certainly not. I believe that they are leading the way they deem best and with the information they have available. If nothing else this is a venue to express free thought and my own personal take on the situation. So if there comes a time when faced with the decision of how to handle a situation where tough decisions need to be made, don't shy away from getting help from your employees. It's not a showcase of weakness when you come to people with requests for help. Indeed I would argue that it reflects your trust in your engineers that they can come up with something that will get you out of the situation. Realize that there are no magic pills and that often it's necessary to make some sacrifices in the beginning (think about the time it will take personnel to fix the issue). Just remember, these are the people you hired to do a great job. Equip them to do that and they just might surprise you.