How to Lead Your Teams
Project managers can be labeled a number of things- PM, Project Administrator, Project Coordinator, Producer, sometimes even a Product Manager. The job duties may vary slightly between these titles or the industry could dictate the title, but they all have a similar basic skill set. Be organized. Have great communication skills. Be punctual and responsive.
Personally, I don’t really care what my title says I am. I know what I contribute to my teams on a daily basis and it’s a huge range of skills, so it doesn’t matter what I’m called. However, when someone sees my title as “Project Administrator” and assumes I’m an office assistant, it doesn’t sit well. Certainly, some of my tasks are administrative (I mean, how do you think the money ends up in your bank account?). On small teams like Zaengle, many of us wear multiple hats. It’s not what your hats are called, it’s how you use them!
Some of my hats at Zaengle as a “Project Administrator” include managing our payroll and benefits, project management, and client relations. I enjoy being the point person for my teams. If they have questions on anything from paychecks to projects, I get great satisfaction out of helping squash uncertainties. The less they have to stress about operations, the better they can do their jobs. It’s a synergistic relationship that flourishes when each appreciates the other.
Reflecting on Weaknesses
In my recent Q4 review, Jason asked a great question. I don’t remember the exact wording, but it was something along the lines of “what do you want to improve most with your work”. Pretty generic, nothing crazy. However, I had already been thinking about it for a few weeks. I’m organized, I’m prompt, and I can communicate with our clients well. One thing I feel I struggle with is managing the dev side of projects. We have brilliant developers, but sometimes I feel like they’re speaking a foreign language (I mean… I guess they are technically speaking a different language).
I go back to my grad school days studying Exercise Science. There’s kinesiology and there’s physiology. With kinesiology you can touch, feel, measure, see the body moving. In physiology, it’s more abstract. It’s at the cellular level. Sure, you’re able to measure all sorts of things at the cellular level, but you’re looking at things with a very different mind set. To me, this is the difference between design and development. Design you can look, touch, feel. Change the colors, see results. Adding texture, makes it feel like this. You do something and you see an immediate change. With development, it feels hidden, like at the cellular level. In theory, I KNOW what they’re doing, but it’s a high level nitty gritty, must be precise or you’ll cause bugs- type of change.
I always preferred kinesiology.
How to Do it Better
I haven’t been at Zaengle a tremendously long time, but I know I’d like to stay here for a while! To ensure I stay relevant, I want to make sure I do my best to continue growing and learning. To jump start my 2018 goal of improving, I tried to break down into tangible action items.
I hope to read or listen to as many books as possible. Not just “work” related (the work brain needs to shut off sometimes!), but in general. It’s another weakness of mine- not taking the time to slow down and simply read. The hope here is I can learn from other people’s experiences. Gain insight into what has worked, what hasn’t.
Have real conversations. I needed to get to know my developers and just chat! What a crazy thought, eh?! Get to know them more as people, not just developers. Figure out what they like. I’ve discovered Owen has chickens and likes Folk Americana. We’re a lot more similar than you’d initially think! Jesse is an incredible woodworker and lives in Northern Wisconsin (close to where I’m from). I feel like these types of commonalities help create a real relationship that makes it easier to have two way conversations.
Dang, this is hard. I want to know everything right this second! I want to be the best, RIGHT NOW. I have to be patient and give it all time. Give myself time to learn new things.
I went straight to the source! I asked my dev team what I can do better or what specifically I could learn so I could feel more confident speaking their language. I got all sorts of warm fuzzies when Jesse, our back end wizard. He gave a great analogy of when he and his wife took a trip to Mexico. Neither knew much Spanish, but enough to communicate a few basic needs across the language barrier. He said they relied on the good will of others to help them. This translates into our relationship because we’re each the expert in our areas (project management and development). We each know some basics of the other’s language. Beyond that, we rely on the good will of each other to communicate our needs. By showing good will and a little appreciation for each other, it build patience, confidence, and trust. Jesse’s story invoked a great deal of confidence in me; the confidence that I don’t have to be afraid of not knowing his language fluently. As long as we’re communicating, we’ll figure it out together!
Owen further backed this theme up. His best recommendation as a developer is to ask questions. This, of course, helps me to learn more about what he’s doing or what our needs are. In addition, it’s helps him learn to better articulate what he’s working on.
I feel fortunate to have team who is supportive of each other’s successes. My goal for 2018 is to up my “dev” game and continue honing my ability to communicate with all my teams. It’s an exciting challenge that isn’t so scary when I have a BA team to work with.
So how do you manage and engage your teams- design or development? What have you found that helps you better connect and understand?
EQ- Part I
Let’s make one thing clear. No one is perfect. No one is the perfect leader, a perfect friend, or a perfect partner.
Using WhereHas in Laravel Polymorphic Relations
Have you ever needed to use a query constraint on a Laravel polymorphic relationship? Here's a method that has worked well for me!