Dev Managing …

Featured, Tech, Development Manager  · 

Someone at work asked me to write down what my expectations of a Dev Manager are. So here they are. These notes are cobbled together from my readings, talking and observing other Dev Managers, and a little bit of experience. I’ve added some resources at the end that might be helpful.

The most useful book for me personally is The Manager’s Path by Camille Fournier. An excellent book.

While the reading and research are important (and doing so puts you well ahead of most people doing the role), there’s no substitute for doing. The best way to grow is to get lots of varied experiences.

Disclaimer: these are my personal opinions and what I try to do. Others will do the role differently. Seek varied perspectives.

First, Senior Devs

The focus of a senior dev is about what they can do. While leverage increases as you progress along a technical track, the primary way we measure impact is what things you produced (be that code, products, design docs, learnings …)

Second, Team Leads

Finally, Development Managers

In my opinion, the focus of a Development manager switches from themselves or a few individuals, to the team. The team, in turn, delivers the results to the organization. However, the dev manager is still a member of the team and has responsibilities within the team.

The move to Development Manager is a subtle but important shift, with changes in mindset, reward mechanisms, and skills needed.

Corresponding to the mindset shift is the lack of a dopamine hit of building. That signal has to be replaced with the satisfaction of team success. Team success is more diffuse than individual success, and that reward feeling is hard to get used to. Charity Majors has a great post on how hard this can be.

The skills shift is really around team management. You have to convince a bunch of talented and opinionated folks to get behind a vision and a plan and push in the same direction to achieve something. Technical experience helps, but isn’t sufficient.

Three Areas of Focus for a Dev Manager

In the context of building a team, I see three areas of focus for a dev manager.

People

Obviously, people are the building blocks of the team. It’s the responsibility of the Dev Manager to evaluate, place, challenge, grow, and augment the people on the team.

Mentoring, Coaching and Designed Alliances

Lara Hogan captures what I think encapsulates the difference between mentoring and coaching.

Mentoring is roughly “having a set of skills and imparting those skills to someone else.” This makes the most sense when someone wants to level up along a predefined direction. For example, “Jim wants to be a better backend dev – perhaps someone can mentor him.”

In contrast, from Lara Hogan:

Coaching is super different than mentoring; as a mentor, we’re sharing advice and our perspective on whatever the mentee is going through. But as a coach, we step out of problem-solving mode, and into curiosity and active listening mode — our goal is to help this other person introspect and explore their challenge for a while, before figuring out next steps.

(Emphasis mine)

When having these conversations (especially in 1-1 conversations), we should be very mindful of whether we are having a mentoring or a coaching conversation. It’s best to ask the person what kind of conversation do you want to have?

This question can be framed in terms of the “designed alliance” which an agreed format of discussion, with guardrails, topics that are in- and out-of-scope, and a way of re-evaluating when the format will change.

Alignment and the Right People on the Bus

People are not fungible cogs that we can put on teams and point them in a certain direction. As managers we have to be aware of their goals and dreams, and try to build an environment where they can succeed.

At the most fundamental level, our people have to be aligned with the company’s mission. Then they have to be aligned with the team’s mission and goals. It’s a dev manager’s job to translate how the mission and the strategies affect a team member’s day-to-day job, and give them room to grow within that mission.

The maxim from Jim Collins is “get the right people on the bus, in the right seats.”

The “bus” analogy can be applied from the highest level (the company, as above) down to the team. In general, I would hope that people who are now at a company generally align with the mission of that company.

The bus (at the team or product-line level) should be big enough that you can move and shuffle seats and people will generally be happy.

Some people like being on the bus for the scenery they’ll see along the way. Also fine.

Some people don’t like where the bus is going. It’s fine to let them off for them to get on their right bus. That might be a different team in a different PL, or might entail leaving the company.

Process and Measurement

Since I view the team as the foundational unit, I tend to think of what Dev Managers should be doing in terms of what the team should be doing. This starts with the team members that report into the Dev Manager (engineers) but then extends out to PMs and designers if they are a part of the delivery team.

Teams should ship useful products to customers. For some definition of “ship,” “products,” and “customers.”

The de facto, “modern” way to ship code is some version of an agile process. This might be Agile, XP, Scrum, Bet-Shaping or any other process for delivering software.My main interest here is:

A reasonable place to start is

  1. Build a high level release plan. Use this to chunk / block out features. Timelines of 6-12 weeks (½ to one quarter) work in this range as it allows a reasonable team to ship a reasonably functioning piece of work. After 6-12 weeks, the team can decide to proceed (further investment) or stop based on the value already shipped. See Shape Up for ideas here.
  2. Break the release plan into 2 week long sprints, with tickets bucketed into the sprint
    1. Group the sprint thematically so that something is done and dusted by the end of the sprint
    2. View the sprint as a commitment.
    3. Don’t pivot in the middle of the sprint.
    4. Review the sprint and retrospect on the team at the end of each sprint
  3. Practise to get into good habits.

The measurement should happen on multiple dimensions:

  1. Is the team shipping? Metrics might include
    1. PRs closed
    2. Tickets closed
    3. Deploys
  2. Is the team meeting its commitments
    1. Are issues dragging between sprints?
  3. How does the team feel?
    1. Psychological safety within the team
    2. Pride in work

Technology

Part of managing a team of developers is to guide the technological choices that a team makes, and contribute to team’s code bases.

However, the dev manager’s contribution is different than a senior individual contributor. Because the unit is the team, it’s the dev manager’s job to assist the team in achieving its technical goals.

On the technology front, this could be

Part of this is the mindset shift of “giving away the Legos” and getting satisfaction from others doing the heavy lifting.

Going Further

Beyond the three pillars of being a dev manager, the value-added pieces are …

Works well with others, communicates

There are no “lone wolf”s in management. All software is people, and to build the right things, we have to work with all our partners and stakeholders:

Communication

Communication is hard. And it’s the role of the Dev manager to foster communication. Good communication is at the heart of team alignment and psychological safety.

I would break the very broad topic into:

Understand the audience and venue

The main gradient across the audience is the amount of context people have. The more senior the audience, the more context they should have, and thus the discussion probably focuses on what and how. For a discussion with the folks you manage, the discussion is probably around the context itself, the why and the when. For the venue, communication styles change between a large meeting and a 1:1. In a meeting, we probably want to encourage involvement, which may involve sitting back, asking for others to speak, and maybe even arguing against yourself. For a 1:1 the discussion can be more focused.

Understand the media

Written allows for a record, for comments and for clarity. Spoken is transient. Decisions should be committed to an artifact so they can be referred to. Obviously, some discussions are sensitive, or free-form, and belong in the spoken domain. But again, summaries become useful.

Understand the mode

Communication happens not just by the spoken or written word. Body language, focus and listening are equally parts of communication. Listening becomes especially important for a manager.

For a categorization of listening, consider the Co-active Coaching model of three levels of listening:

  1. Level 1: Internal Listening. This is listening to hear the impact on the listener
  2. Level 2: Focused Listening. This is listening to hear what the other person is saying, not to decide what we are going to say next.
  3. Level 3: Global Listening. This is sensing the entire picture. What the person is saying, what their body language says, how the room is reacting to what is being said.

Manages Stakeholders

Fundamentally, we work for a business. The business has objectives (the most common, make money).

As our work ladders up and down, we encounter and interact with a wide range of people and teams. Each of whom have their perspectives, desires, commitments, and fundamentally, needs. As leaders, but more importantly managers, it falls on us to manage stakeholders.

Stakeholders, at the most basic level, are people with a stake in the outcome (yes, obvious, I know). This is not synonymous with “our bosses.” Stakeholders include our partners in R’n’D, in marketing and in customer success.

Opinions

You will be asked opinions on feasibility and viability of an upcoming decision or choice. It’s your responsibility to answer these questions as honestly and forthrightly as possible. “I don’t know” is a perfectly valid answer, as long as it’s followed by “I’ll find out within ”.

In my opinion, it’s best to answer the question as posed, modulo clarifying questions. More senior staff may have additional context about why they’re asking, but it’s not incumbent on them to explain why they want to know.

Estimates

In addition to opinions, you’ll be asked for estimates. Be careful, as these tend to become commitments. However, resist the temptation to pad or sandbag your answer. “I don’t know” is also valid in this situation.

Here it’s good to ask what the outcome we’re trying to achieve. Perhaps it’s best not to estimate any code, and achieve the outcome some other way. Knowing the outcome also allows you to consider the tradeoffs between estimated work and ongoing work.

Feedback

We say that feedback is a gift. There can also be a power dynamic involved, so consider how you want to give feedback. My advice would be: for more senior people, we tend to shy away from feedback, whereas they probably gain an outsized benefit from the “word on the street.”

Conversely, we tend to offer unsolicited feedback to our partners and juniors more often. Here care and consideration, and asking “hey, can I offer some feedback?” goes a long way.

Conflicts

Finally, stakeholders have different priorities and needs. And those priorities will manifest in different ways onto your team. You have to find a way to synthesize those priorities into a plan that makes sense for you and your team. Then communicate that plan back to the team and to stakeholders.

Extends the timelines and leverage of the team

A good development manager will have a multiplicative effect on the team, getting more out of the team members than the sum of the parts.

A digression into tactics vs strategy

To be honest, everyone has a different definition of “strategy” and “tactics” and where they apply. We often hear “that person is too tactical, they need to be more strategic,” without defining either tactical or strategic.

An oft-used maxim is:

Tactics == do things right. Strategy == do the right things.

Or another simplistic way to look at strategy / tactics is through a lens of scale. Strategy is just tactics on a longer time-scale.

Both of these are simplifications.

The most clear definition of strategy in business that I’ve seen is in Good Strategy, Bad Strategy. It breaks down into three components

A dev manager should be looking further down the road for challenges (both positive and negative) that we will need to overcome in the future, and planning in the strategic sense (in partnership with product & UX) to overcome them.

Makes Great Decisions Quickly

A dev manager ends up being on the hook for making decisions that have a larger effect than that of an individual developer on a team. One might have to arbitrate a technology choice, or a product decision, or a deadline or a personnel choice.

In general, we need to be comfortable making decisions with less information than we might like. A rough heuristic is that we should be making decisions with ~70% of the available information. If we wait for 90-95% of the information, we’re waiting too long and we incur an opportunity cost.

One way of thinking of this is to divide decisions into two types:

The tricks are two-fold. The first, recognizing the difference a priori between Type 1 & 2. And second, observe that most decisions are in fact Type 2.

When Do These Things Happen?

While the job breaks roughly into the three areas mentioned above, the activities are not spread equally across either time, or the people doing the job. For example, people management may take precedence during reviews, or if there is a particular issue with a team member. Architectural designs, RFCs, etc may be front of mind when a project kicks off. Procedures and rituals may need to be set when building a new team, or when things stagnate.

Further, different people do the job differently.

Doing the Job Differently

Because the role has so much flexibility, and is focussed so much on outcomes, it’s really possible to do this job lots of different ways.

Some folks will focus on the tech. Build an architecture that serves as a foundation that people can add to, and set them loose.

Some will start with the people. Dig into their motivations, and attempt to get them in the right spots so they can own the team’s outcomes.

Finally, process and measurement might help. Build a repeatable process, measure its outcomes and fine-tune it along the way.

Personally I’m a “people” person. Others lean to “tech”. I’ve never found “process heavy” to work particularly well.

Where to Start?

I’m about to contradict myself. Even though process-heavy isn’t a great way to run a team, process is a reasonable place to start. Lightweight, repeatable rituals help build team alignment and force us to investigate what’s good and what’s not so good. It’s something that can be instigated at almost any stage of a project. It also doesn’t require big up-front decisions, or long lead-times to get to know people. If I had to pick one of three areas of focus to begin “Dev Manager” tasks, I’d look at the team dynamics and rituals. Some questions to dive into:

Meetings:

Processes

If we have sprints, do we measure their effectiveness? Could we predict a release based on past data?

Does the sprint represent a commitment, or just tracking?

Do we attempt to improve the team dynamics (retrospectives)?

Team Ethos

Does the team have founding principles (e.g. “ship early and often” vs “zero defect escape rate”)

Is there tension on the team about the team’s ethos? Do we ever revisit it?

Who sets the tone on the team?

Conclusions

Dev Manager is a hard and varied role. It’s a mix of people, process and tech, and requires skills adjacent to being a software developer. You’re in the team but not really of the team.

Lots of people do it differently and have success. It’s deeply rewarding to see teams ship amazing stuff when all the pieces are in place.

References

Books and sites that I found very useful. More to follow