Note: This is the first part of a three part series. Part 2 is for designers, and Part 3 is for developers.
After more than 18 months working as the “Implementation Team Manager” (a developer and project manager) with Delta Defense, LLC I have left to join WebDev Studios. I’m making this transition so I can focus more completely on WordPress development. It sounds like a fun thing to do and, though I’m sad to leave Delta, I’m very excited for this opportunity.
In my final days as an employee and team manager at Delta I took some time to impart my limited amounts of wisdom with my teammates. Most of my advice was very personal and specific to the person with whom I was sharing. Some of it, however, surprised even me and I thought it best to share it here with you, too (mostly as a reminder to future-me that past-me was a pretty smart guy).
Being a Leader
Being in the leader seat carries a certain amount of weight and responsibility. It basically means that you’re solely responsible for every single project the team produces, and that you won’t be the person building the majority of them. It means a lot of time spent jockeying emails, and not a lot of time actually creating. In short, it means than if you really like to build and tinker, and don’t like to spend most of your day in email and Basecamp, you need to seriously consider whether or not you’d actually want to climb into this seat.
To help you with a decision like that, I wanted to offer you up some things that I’ve learned from my position and over the course of many, many years doing all the things that we do.
1. Everyone is important, Everyone is Replaceable
Each person on my team, myself included, is tremendously important because of their unique knowledge, perspectives and experience. Their ability to understand how things work, along with a passion for learning more and doing better, makes each person a tremendously valuable asset. Still, it’s important to realize that, even as the most important person on a team, you’re no less replaceable than any other person. So, never forget that and never rest on your laurels.
2. It is HARMFUL to both you, and the company, to work more than 8hrs per day, 5 days per week.
It’s okay to break this rule every once in a while, for things like large launches and the like, but you should absolutely NOT standardize your work life around putting in more hours than that. In fact, your goal should invariably be to work as few as possible without decreasing throughput.
The more hours you work the less effective you will become. I’ve experienced this to be true in my own life and witnessed it to be true in the rest of my team. On a whole, a company that has employees who work more than 40hrs per week on a consistent basis will run into innumerably more problems than a company who does not.
You should train the very core of your being in a way that it will react strongly and passionately against working past 5 or on the weekend. Alarms and warnings should go off in your mind when you decide to work any extra hours (UNLESS the payoff is leaving early or starting late a different day, or simply clearing your plate so you can be mentally renewed the next day. Even then, it should be rare that you put in any extra time).
The simple truth is this: nothing in this (or any) job is worth more than that, especially compared to your marriage, family and personal well-being. You prove yourself more valuable by your ability to accomplish much in little time than you do by your willingness to work long hours.
3. Remember Your Role as a Manager
As a manager, any time you’re personally doing a task that we pay someone else to do, you’re doing it wrong.
In other words, always offload every (and I mean every) project and task you get to someone else on the team. Do this until your inbox is absolutely empty and every single task has been assigned to another person with decent instruction and a specific deadline. Then, cycle through each project (starting with those due soonest) and ask questions about their progress, provide additional context or instruction where necessary, and only assist with a build when someone really needs help.
I was definitely worst at this one. Any time you think you need to spend personally working on a build is always better spent demonstrating to someone else how to build it. There are certainly times where you can solve an issue in 60 seconds that would take 5 minutes to explain, and even in those cases where you fix it yourself you should still take the 5min to explain what you did and why. That way, the next person is better equipped to handle similar situations in the future and you’ve removed yourself as a bottleneck.
The role of a leader is to remove barriers and communicate effectively. You communicate with the project requester so that you fully understand their needs, then you communicate with the project executers so the build is done to specification. In between request and delivery you should be maintaining communication with both sides to ensure everything stays on-track and, if things fall behind, they’re caught immediately so everyone can plan accordingly.
In other words: your team is your greatest asset, you should trust, enable and rely on them to do everything.
This brings me to my fourth and final point:
4. You are always wrong.
Always give the other person the benefit of the doubt and ask them to explain things from their perspective. Assume you’re wrong or that you misunderstood first and foremost. This helps you to remain humble and avoid unnecessary conflict. Conflict is good and healthy for resolving problems, but putting someone else at fault is never the correct course of action and is almost always non-productive. If someone else has failed to deliver you what you expected or needed, first ask yourself how you could have explained it to them better. Did you not emphasize the importance of timing? Did you not explain another piece of context?
If a project ever falls behind deadline it’s either because (i) the deadline wasn’t clear, (ii) the project was less important than something else, or (iii) the importance of this project wasn’t clear. Much of what you’ll be doing as a project manager is assessing project progress and renegotiating deadlines, so try night to get too put out by how frequently things change.
When someone fails to deliver something you needed (either when you needed it or how you wanted it), instead of getting upset with them try to understand what they thought you meant and learn how you could have gotten them what they needed to hear.
Your mileage may vary…
This is what worked for me as a leader. It might not work for you, but I had a lot of fun following these four principals. I’d love to hear your thoughts on the matter, so please drop me a line in the comments, as @rzen on twitter, or via my Contact form.
Leave a Reply