Why your engineering team might need managers, after all
What matters is the journey. Not the posture.
From its creation in September 2019 to November 2022, the engineering team at Pigment had a flat hierarchy. Our first hires were senior software engineers. They had been through management and organizational complexity before, for the good, the bad, and the traumatic. It was our wish to preserve flexibility over structure for as long as possible. We all reported to our co-CEO.
But when does it break? At Pigment, we prefer to think about what we need, rather than going for predefined roles. With this in mind, we tried to secure organizational alignment, implemented coaching, and iterated on technical leadership. But at some point, we could no longer sustain our way of work: here is why we chose to have engineering managers.
Organizational alignment
In this podcast, Katie Wilde, VP of Engineering at Ambassador Labs, makes this point: holacracy is an answer to bad management. It will generally not work above a certain organizational complexity. More precisely, she insists on the difficulty to make decisions in a vast and decentralized environment.
Pigment has never been a holacracy: we always had some kind of alignment, for instance on product priorities. Yet, the connection she made rang a bell for me. That we might reject management for the wrong reasons was making me uncomfortable. While I appreciated the velocity and the minimal overhead of our organization, I was also in charge of scaling processes for the technical team. The increasing complexity was becoming difficult to manage in a flat structure.
The breaking point was reached in September 2022, when we approached the mark of 45 persons in the technical team (30 software engineers).
I shared my problem with my counterpart, who is in charge of technical leadership. Turns out, he was having the problem too: whenever we needed to make a topic progress, we were playing “eenie meenie miney moo” or putting in calls for volunteers. For a boring topic, I had 14 volunteers. For one I was excited about, I had 2. On top of that, I was never sure who had seen the information I broadcast. I could not realistically ping every single team member to make sure they had.
Who gets to decide who gets to decide who gets to decide who…
I had already tried many things to work around these problems. In Spring, I even had to organize a workshop in order to decide on, well, decision-making. Yes! It does sound a bit “meta”, I know. Retrospectively, this was one of the first signals that our model was reaching its limits. Some good came out of it though:
- We clarified our official channels of communication: information and decisions are shared in the developers’ channel on Slack and persisted in our weekly newsletter on Notion,
- We added emojis to positively appraise technical design documents. Until then, they did not receive any kind of acknowledgment except comments (meh),
- We officialized a decision ladder,
- We identified needs that could be addressed immediately. For instance, 2 software engineers launched a task force overseeing changes to our design system, right out of this meeting.
All of these elements are part of our culture now. But that was still a bit artificial. I felt like I was trying to keep a puddle from spreading…by planting sticks. It was clear to both my counterpart and me that we needed to distribute responsibilities more, and that we should look out for our first managers.
I wasn’t sure our conviction was shared by all, though. What exactly had my coworkers expected of Pigment when joining? Did they think we would NEVER have managers? or that management was intrinsically bad? What happened then is a nice planetary conjunction, as another need materialized.
Career management
It’s difficult to understand expectations in a young company as career-related mechanisms are not in place. This is particularly true for coworkers in their early professional lives.
For some months already, our answer to this need had been coaching. Our guiding principle was this: to provide a space that makes it psychologically safe for the coachee to discuss their performance, difficulties, and aspirations.
Coaches were meant to
- collect feedback,
- help coachees make sense of it in light of their objectives,
- and support them in formulating and executing the right solutions for their challenges.
It sounded good on paper, but it didn’t work super well.
Coaching requires a specific posture. In a coaching relationship, the coachee is the expert. The coach is not supposed to particularly know of the coachee’s day–to–day or domain. It made sense to us because we wanted a neutral role, that could not be confused with management. This neutrality is also how we found willing coaches.
However, it was also the limitation of the role. It is one thing to have coffee conversations with coworkers you like and genuinely want to help, but what if difficulties arise, and tough conversations need to be had? Clearly, some of our coaches hadn’t signed up for that. Neither had they signed up for the next big topic we had in mind: career management.
In 1:1 interviews led by the People team, half of our software engineers expressed a need for more structured progression. In addition, having fair visibility of everyone’s contribution was no longer possible due to the size of the team. So we wanted to define unbiased criteria for the upcoming compensation review cycle, at the end of the year. That meant having a career ladder in place and defining seniority levels.
This is when planets aligned. It happened unexpectedly during a call we had with coaches. My counterpart and I expected to be walking on eggshells when bringing up management, but coaches brought it up themselves. Most did not want to participate in career-related decisions. If they did, they would effectively become managers. As coaches, they could not deal with decisions made by someone else, either. So, they had reached the same conclusions as we did.
When we finished that call, I had mixed feelings. Coaching would be dropped, and replaced by management. Part of me was sad about this outcome. I am a strong believer in coaching and I regret it was so short-lived. But my biggest problem would be solved: about that, I felt like landing the perfect shot without even trying. Oh, there was still a tiny, tiny detail to take care of, of course: finding managers. No “eenie meenie miney moo” this time.
Technical leadership
Defining managers helped with organizational alignment and career management. But there was one last problem we did not solve: my counterpart needed relays for his technical leadership. How could we, for instance, maintain a technical vision of a domain spanning over multiple teams? Or coordinate all of engineering to improve our observability practices and tooling?
In fact, we already had technical leads. They were rather honorific titles held by the most knowledgeable member of a given component— merely points of contact, incident responders, and PR reviewers. But we had way more reasons to have this role now than we did 6 months before. In addition to these much-needed owners of large-scale initiatives, we wanted to better consider engineering priorities when planning our sprints, tackle technical debt more proactively, and secure knowledge redundancy. We revamped the role and systematized it in every team.
We led this effort alongside our quest for managers. What connection did we expect between both roles? We could not appoint the right persons without clarifying it. Our decision was to separate technical domains from management, that is, we did not define managers based on technical scopes. We decided that:
1) Hierarchy should not influence technical decisions. Technical leads work on their scopes independently from people management. It does not mean “no supervision”. Courageous decisions still have to be taken (in fact, that’s my counterpart’s job). But a disagreement on technical choices should not create a conflict between an engineer and a person who has power over their career.
2) A change of technical scope should not depend on the manager, and reciprocally. Software engineers tend to stay on a scope so they can stick with a manager they like: we wanted to prevent that from happening. Also, a change of manager would have been difficult if there was, for instance, one manager for all front-end developers. All in all, this choice made mobility easier.
This setup also secures an important point: technical leadership and people management are two different career paths. This is relatively obvious across the industry now: engineers should not have to give up on career opportunities because they decide to remain individual contributors. There are many great ways to have an impact by pursuing an expert track or applying a unique combination of skills and traits.
The corollary to this point is equally important in my eyes: no one should become a manager if they are a disaster at handling people. This toxic mistake has often been made in tech companies when trying to “reward” their most technically proficient members. So, if I could write this sentence even bigger and bolder, I would: there is no need to appoint people managers who are not truly committed to developing their team members.
…
Oh, wait, I actually can!
There is no need to appoint people managers who are not truly committed to developing their team members.
Takeaways
When working at a young company, it is tempting to try and do differently. We want to do good, avoid reproducing the usual sources of drama, and let’s admit it, try to sound a little bit smarter than the others. In practice, doing things in an unusual way requires an intentional effort.
We work in a favorable context for this: as tech engineers, we are privileged in the job market. Our engineering team is a profit center. This position gives us a lot of freedom to challenge common dysfunctions in companies, whether managers, meetings, office politics, or performance reviews. And while we can’t get rid of the source of our greatest fears, that is, people, nothing prevents us to remove what “doesn’t work” and see what happens.
It’s good to have such a space to experiment, in a way. It certainly makes my job more interesting. But the risk is to define culture by what we don’t want: doing so hides the cost of making anything work. You don’t fix lousy management with a holacracy. Neither do you have, say, an asynchronous culture because of bad meetings you have not even tried to fix. Either way —whether fixing or innovating — you got to want it badly enough (they did). I don’t think we wanted coaching that badly: we wanted an alternative to managers. And it took us some time to find, for each individual need, a solution that would work with all the others.
I tend to view the last 9 months through that lens. We tried things, patched the organization wherever necessary, succeeded in some places, and failed in others. We had a first version of technical leads that was good enough until we built a better one. The relationships built between coaches and coachees are still lasting, some being continued by managers. And this dual track between managers and technical leads, while being common, has been functioning well over the last few months.
Culture is not just the sum of its elements. It is also what holds them together. At Pigment, we glued together organizational alignment, career management, and technical leadership, by staying true to our principle: we preserved flexibility over structure.
My job is to scale engineering teams at Pigment, the next-generation business planning SaaS for companies (www.gopigment.com). I read and write about project and program management, product management, organization, soft skills, productivity, DEI, well-being, and personal development.
If we share common interests, follow me here or on LinkedIn.
