Back to blog overview

October 5, 2021

ZEAL Engineering Principle: There are roles, not departments

Jason Harrison

&

&

Chief Operating Officer
Medford, OR

This is part of an ongoing series on principle-driven consulting. Read previous blogs, here, here, here, and here

While we have designers, engineers and product managers, the entire team is responsible for delivery. “Departmental responsibility” leads to isolation; whereas roles are added to a team based on the needs of the project, and played by one or more people.

Departments are hard, but why?

When the organization is divided by departments, it creates a few speed bumps, if not roadblocks, to effective delivery. Get curious and ask yourself a series of questions as it pertains to interdepartmental communication, alignment and feedback. 

Communication: What happens when communication has to cross a departmental boundary? Does it lose something - some fidelity, some detail? Maybe I don’t get it at all. Maybe someone forgets to keep me in the loop because it’s overhead for them to remember all of the departments that are involved. What mechanism makes sure I’m aware of what’s going on in other departments so I can help and support?

Alignment: How aligned and engaged can I be with a project or product that is owned by a department other than mine? If I don’t feel like it’s mine, how does that change the way I engage? Am I aligned to the company’s goals, or my department’s goals? If they're not aligned, how will I prioritize my focus and effort? 

Feedback: Where do I go for feedback on a cross-department project? What opportunities do I have to grow, and who’s supporting them? Can a cross-department manager talk to me like my own manager would?

These are just a few of the dynamics that departmental structures can introduce. Getting curious can help navigate departmental roadblocks, seen and unseen so people can do their best work.

What about roles?

One of the things I love about roles vs a department is that they’re so flexible! That’s not to say, as a non-designer, that I should play the role of designer on a project. Who am I trying to kid?! 😂

It does mean that designers and engineers can also play the project manager role. Everyone can play the mentor role. They also can overlap departments which helps to bring people together. 

We’ve had team members who expressed interest in other roles, and we’ve supported their growth in those roles. It makes the whole team better when the players can be organized into strong units formed with complementary roles.

It’s certainly okay for someone to focus their energy in one area, such as software development, but organizing by role, rather than department, gives us the flexibility to support team members with varying interests and desires for growth.

Working from the context of roles gives me a chance to learn a new one. As a software engineer I may want to learn how to manage a project, too. As a designer, I could also learn a backend framework. There’s nothing stopping me from doing that. So maybe I can be a designer on the next project. 🤔

What about growth?

Roles are cool and all, but if I don’t have a department head, who is going to help me grow, and advise me on areas of improvement?

We all want to get better, and often assume that we need a manager that is, or has been, what we’re trying to grow into. There’s nothing wrong with this assumption but it is only one way to get there. 

Even though I manage a lot of people, I don’t try to be an expert in all of the things they do. I can’t. I don’t have time. What I can do, though, is help arrange mentorship, inside and outside of the company. I can pay for books, courses, conferences, and tech talks. I can support the team to grow into the roles they’re interested in. I can connect them with experts in my network, etc. 

When someone is looking to grow into another role, I’ll support them with whatever training I can, and then I’ll find a project where they can start to exercise those new muscles. Sometimes I’ll consciously stick around in a mentorship capacity and then slip away as they gain confidence. 

How do I know if they’re doing well? I can typically count on team members to be pretty self-aware, but I also get feedback from folks on the same project, as well as the clients themselves. There’s no shortage of feedback when you ask for it.

Organizing team members into departments can lead to friction from misalignment and poor communication. This can all lead to rigid definitions of who we are, and what we do. Organizing by roles, in contrast, offers greater flexibility, not only for a project, but also for a person. We all want to grow. It’s nice when we can support people growing into different roles, and contributing to a team in new ways.


Photo by "My Life Through A Lens" on Unsplash

Let's Chat

Are you ready to build something brilliant? We're ready to help.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
RedwoodJS Logo
RedwoodJS
Conference

conference
for builders

Grants Pass, Oregon • September 26 - 29, 2023
View All