Hi Mathias,

I work at a professional services company with about 150 people. We have six practice areas. Each practice helps clients by delivering technical solutions to meet business needs by either implementing infrastructure, security, or custom applications. I currently lead about 30 engineers who support one of those practice areas. I manage our delivery practices, resource/team management, and technical strategy. I come from a software engineering background, and still code when I can.

I’m being asked to lead all of the software engineering people across all of the practice areas (about 50 people). There are no currently defined job titles for senior technical leadership, aside from the CTO, who is more outward-facing. My new position would be new to the company. I am not sure what title to push for, or how to help form the org chart. I think of myself as a VP of engineering, but our non-technical COO thinks of an enterprise architect.

Is there a good reference as to what an org chart should look like for technical folks, including a career ladder?"

— Dakarai

I see two challenges in the request. One is about where you fit in with the organization, as it clearly needs to evolve into something that’s managed with more intention. The other is about how you draw an org chart and career ladder for the organization. This most likely involves coming up with new roles for management that didn’t exist before, or at least have not been clearly defined. As both are a deep challenge in their own right, I’m going to focus on your own role, which will also help set the stage for how you can then think about the other roles needed in your organization.

Defining your role

The upper echelons of engineering management are especially difficult to pin down and navigate. Titles bring certain expectations and responsibilities, some of them pretty vague, others can vary wildly from company to company. 

With your role, it seems like there is a lack of clarity around the expectations for this title. Start with the expectations and responsibilities you see on different levels in your organization, including your own. With a list of these, it can be easier to sync up with the different folks involved in the decision and discuss what is truly part of your role. When that negotiation is done, it can be easier to find your spot on a career ladder, or even to create one for your engineering organization and yourself.

Here’s how you could structure that process, by answering each of the questions below based on conversations with yourself and the people around you.

What are your key responsibilities, now and potentially in the future? 

Keep these concrete. Instead of writing “people management,” write out what that means in practice. Maybe it means you’re responsible for running a healthy engineering team, or for career, learning, and growth opportunities. 

Instead of “processes,” maybe you’re responsible for team efficiency and effectiveness by introducing new processes, constantly iterating on existing ones, and shedding anything outdated where needed? 

Instead of writing “strategy”, what’s the responsibility here? Maybe providing an engineering strategy? Spending more time thinking ahead? Taking your hands fully out of coding work? 

The resulting list isn’t just a starting point for your discussion. It’s meant to provide you with ultimate clarity on the things you do and what you steer clear of and delegate to others.

What expectations should your stakeholders have towards you?

Here you need to look at your role from the perspective of the business. What’s the ultimate outcome of your work in your role? Is it a healthy team or a regular cadence of value shipped to your customers? Interactions with customers or keeping tabs on current technology trends so that they can be used in upcoming client projects? 

There are typically clues to be found in what your COO thinks your title should be. Talk to them about what they expect from the role of an enterprise architect. This conversation around expectations can be had with any of the people in senior management. Maybe they’ll just tell you they expect you to ship valuable things to clients on time. But even that’s a clue for you.

How will I or my organization measure my success?

In this new role, it’s helpful to be clear on the value you provide to the business. This is likely going to involve delivering projects successfully, on time, with the highest quality, all without sacrificing scope. It could also be something unique to your organization and its clients. 

Think about what your clients value the most when working with you and the other practice groups. What does success mean for each? Hint: your business most likely doesn’t care about velocity, story points, commits, or any other metrics associated with engineering management. What you should aim to find is what these metrics ultimately contribute to, which is most likely about what helps your business be successful. 

Also take the time to think about what’s important to your people. Do you value healthy working hours, team health, retention, hiring success rates, or something entirely different? If none of these resonate, think about what standard you want to set for your team and how it can be measured. Note that measuring success isn’t the same as setting goals, it’s not even the same as using a framework like Objectives and Key Results (OKRs). It’s all about having meaningful indicators that allow you and your team to see whether you’re on the right track or need to adjust to get back on track.

What areas do you want to stretch yourself into?

The great thing about designing your own role is that you also get to think about what areas you may be interested in extending yourself into, such as strategy, hiring managers of managers, or managing stakeholders or peers – like your COO, who has certain expectations towards your role. It’s best to be honest with yourself on what you don’t know or what you’re not yet experienced with. Learning new things is part of growth and contributes greatly to how happy we are at work. With this list, you can think about whether you want to start working with a coach or a mentor to fill in the blanks. 

For each of these questions, I suggest you end up with five to seven items each. If you have more, it’s worth going through the items, looking for patterns and commonalities and distilling them further into areas like people management or strategy.

This whole process gets simpler if you are able to incorporate perspectives from other people in your organization and how they view your role. Doing this will make it easier to convince them that what you come up with will work for most folks. As an added bonus, the role you end up with will most likely play into their respective needs, helping to build and maintain healthy relationships with all of your peers and stakeholders across the organization.

This process isn’t just designed to work for you, it helps for every role in your organization. Asking these questions at each level of your organization can help create a career ladder that’s suited to your specific needs. No matter where you start designing your organization’s structure, the questions I outlined here will be useful to define any role in the hierarchy.

– Mathias