If there’s one thing I hate more than being micromanaged, it is having to actually micromanage someone. I have had my fair share of working for and with managers who want to have a say in every aspect of the work done by their teams, and that just seems like such a miserable existence to me, akin to telling my keyboard how to convert my intentions into electrical signals, or telling my car engine how to, uh, engine. Yes, yes, referring to people as inanimate tools that you use is probably not a great analogy. But then, I’m not that great of a person.
Moving on.
My job as a manager is to make sure my team succeeds, because if I could do all the work my organization needed done, I could just do it myself. It doesn’t matter how great of a developer I think I am, I am bound to make more mistakes than a team of developers. Having more people ensures that my company doesn’t have to pay for the sum total of all of my mistakes.
Mistakes Happen
Speaking of mistakes, the first rule of software development is, people will make mistakes. Doesn’t matter how experienced they are, doesn’t matter how much testing is performed, mistakes will happen.
Technically minded people tend to think in binary terms more often than not, and getting them to accept this is often difficult. This doesn’t mean delivering a sub par product is acceptable, of course, but once they understand that making a mistake is acceptable in my team, I can actually see a marked increase in their performance.
I Lower Hanging Fruit
As I mentioned in my previous article, people go through quite a bit of testing before they join my team. The upside to all that testing is, before they start, I have a pretty good understanding of their development ability, and I can adjust our approach for their assimilation in the rest of the team to what makes the most sense for them. Even if they have experience in every technology we use, I don’t actually expect production quality work from a new member on the team for at least two months.
If you judge a fish by its ability to climb a tree, it will live its whole life believing that it is stupid.”
All Ducks Are Birds But Not All Birds Are Developers
I have been a software developer for a couple of decades, and have lived many lives at a lot of different companies. At each of those companies, most of the staff was non-technical, and developers were treated the same as other employees, especially when it came to working environments.
Software development isn’t the same as sales or marketing or customer service. Sometimes it takes hours to get to the bottom of a problem, and a simple distraction like your neighbor asking you a question could set you hours behind. So on my team, every developer gets an office they can choose how to furnish, select the type of desk or monitors or peripherals they use, adjust the lights and temperature–and most of all, close the door when they want to without it becoming “a thing”. They also determine the hours that work best for them. It’s not always easy convincing management to allow for such large concessions, but I can do it because it brings results. It’s shocking how well a Lamborghini performs when you aren’t trying to haul lumber with it.
I Encourage Honesty
The world would be a better place if more people would say what they think instead of bullshitting. I understand the need for diplomacy, but there’s a difference between calling someone’s baby ugly and telling the emperor he has no clothes on. I encourage everyone I work with, especially people on my team, to be honest and upfront with me, knowing that if they told me the truth, even if it was unflattering, I would not react badly towards them. I am not paid by my employer to boost my ego–I am paid to bring results. If they trust me to take bad news well, I am more likely to find out about something bad happening when it actually happens, rather than when it gets noticed by others. I am also honest with them when something they are doing isn’t working out, which helps avoid conflict in the long run.
I Bulldoze (Some of) Their Problems
I make it a point to meet with every member of my team at least once every couple of days, and often it’s to talk about something not related to work. Rather than reciting platitudes about how “my door is always open” and “you can always talk to me”, actually engaging in a dialog with my team members makes it far more likely that they will feel comfortable sharing something with me.
Every person on my team is there because they know more about some aspect of our technology stack or our business than I do, so it isn’t often that I can find a solution to their problem on the spot, but I try to fix it for them anyway. I have one on one meetings with each of them every 3-4 weeks, where I ask them to take their most annoying or time consuming problem and make it mine. I will either solve it for them, or find someone who can. This doesn’t always work, because not many people are comfortable just passing the buck on a problem they feel they need to be the one to solve, but I have found that if I keep offering, eventually they take me up on it.
Reality Check
Unless your primary product is a piece of software that is used by other software developers, the work you end up doing is rarely completely aligned with what you think is the best possible way to do it. Technology tends to change much faster than the business around you, and while you’re ready to toss everything that was done over the past two years for the next shiny thing, the business is more focused on the “what” of your tool, not so much the “how”. So a pragmatic approach to real world software development involves balancing the “cool” with the “functional”. And this means that your developers need to actually understand your business, and not just the product they are working on–knowing the “why” behind the “what”.
Keep the Stones Rolling
I make it easy for my developers to stay on top of what’s new by making sure that they not only have access to training resources, but also the time to actually learn new things.
Even the finest sword plunged into salt water will eventually rust.”
–Sun Tzu
Dollars spent on training far outweigh the dollars gained in increased productivity and additional harmony with the muggles. I mean, uh, business users.
Ultimately, this isn’t something I do just out of the goodness of my heart–though it does make me feel great to be a part of a team where people like working with each other. This just makes sense. It takes extra effort on a day when you’re feeling stressed out and annoyed to put your problems on hold and help someone else with theirs, but it ensures the larger machine keeps functioning.
I have fifteen people on my team, with education ranging from high school to doctorate, and with backgrounds in several different fields. This is the first job out of school for some, while some have been doing this work for decades. Some are parents of young children and work remotely, some go to school at night, while some work odd and unpredictable hours. We are immigrants or first generation Americans from eight different countries–many of whom we sponsor. We come from different cultures and speak different languages and have very different experiences, but we are able to function together as a team because there is mutual respect, and a common goal of building things that are, frankly, bad ass. And in all honesty, my job is far simpler now than it has ever been before, because all I have to do is remove the occasional roadblock, and we all go home feeling good about what we’ve accomplished on most days. Even setting aside the feel good element of this setup, this is a far more cost effective way for our business, because this team easily delivers the work product of a team twice its size.
TL; DR; Train people well enough so they can leave, treat them well enough so they don’t want to. –Richard Branson