At times, we have advertised to hire a Director of Engineering, but the first line of the job description says “Director of Engineering is a role, not a job title, and we don’t call it Director of Engineering anyhow.” What does that mean? To explain, I’d like to talk about two ideas driving how we organize ourselves at Galois: no managers, and leadership by council.
No managers. We don’t have managers in a traditional sense, nor do we have a fixed hierarchical organizational structure. Still, the cornerstone of our org structure is the relationship between internal customers and performers, just as the relationship between a manager and a direct report is key in a traditional structure. In a customer role at Galois, one or more performers are fully accountable to you, but only for the results they have committed to producing specifically for you.
Performers typically have multiple customers (accountable to each of them for a different set of results). We are a project-based company, so this idea comes pretty naturally. I might be accountable to the Project Lead (PL) of the Alpha project for Alpha results, and accountable to the Beta project PL for Beta results. And at the same time, I could be a PL myself on the Gamma project, with performers accountable to me for Gamma results. Where it gets weird is that a Gamma performer could also be my Beta PL, so I’m both performer and customer to the same person. These cycles work because “Project Lead” is not a position, it’s a role, and we all have the opportunity to take on many roles.
So, rather than having a typical org chart that looks like an upside-down tree that changes slowly over time, ours can be visualized as a densely-connected, frequently-changing web of customer/performer relationships. In fact, we call our organizational structure the Collaborative Web. Because the majority of Galwegians are in at least one customer role, and because of cycles in the org chart, there aren’t always clear hierarchies in parts of the organization, nor is there really a “top” of the org chart—even our CEO is at times in a performer role to other Galwegians.
As I mentioned, these customer/performer relationships, and how roles are inhabited, change all the time. When the Gamma project ends, I may no longer be a Project Lead, at least until another suitable project starts, but I continue to be a performer on Alpha and Beta. And when the Omega project starts and I’m interested in contributing, I talk to the Omega PL to negotiate a set of results, and may also need to renegotiate my results with the Alpha or Beta PLs. As you can see, all of this is self-directed: I choose the roles I’d like to take on, make offers to perform in that role to appropriate customers, and negotiate results with those customers. Of course, this is tempered by the fact that there is a finite set of projects and other work opportunities, so I may not always get my first choice of roles, or projects.
Leadership by council. It’s probably not surprising to hear that technologists often have little desire to be managers, and that the notion of climbing the management ladder is largely foreign. After all, they are in their chosen field because they are deeply passionate about technology, and have invested themselves (often since childhood) in learning about and practicing with the technologies they love. Becoming a manager distracts from that passion, and consumes time that could otherwise be spent geeking out, building or investigating. This is not to say career advancement is unimportant, but that advancement is typically focused on learning, taking on broader and more influential technical roles, and thus gaining the respect of peers.
Suspicion between management and engineers is in my experience often rooted in the (real or perceived) lack of technical competence by managers. And this suspicion is warranted if the manager doesn’t really have the technical background/experience relevant to the project they are leading. Technical competence is required to communicate well with the team, to earn their respect, and to make even slightly-technical decisions.
So how does the occasional geek that wants to be a good leader manage to stay technically competent so they can be a good leader, and how do they do that without abandoning their passion for technology? One thing that helps us with this is our use of councils.
The Engineering Council (okay, nobody calls it that, everyone calls it the Jedi Council) jointly leads the engineering team, sharing the accountabilities that a Director of Engineering would “normally” hold. None of us are full time council members, which allows each of us to stay involved in the technical work as an individual contributor and/or PL.
At any time, we’ve had 4 to 8 members of the council. Some stay on it for the long term, and some for a year or so. We work to ensure that there is a good mix of representation of various engineering roles on the council—PLs, researchers, and developers. Many council responsibilities are held by a single person on the council, such as leading hiring efforts or overall budget management. Other responsibilities are shared, such as annual planning or being a point of contact for the council with other engineers. Smaller council roles allow an engineer to dip their toes in the water and see if that kind of leadership role appeals to them, without having to make a big change in their career path.
One role that every councilor holds is Jedi Customer. This focuses on ensuring that an engineer is gaining personal value from their engineering roles, that they are getting any support they need in finding project work, and that they are providing accurate predictions about how much time they’ll be spending on project work, as our business model is based on billable hours.
Council Caretaker is a special council role, making sure the council keeps running, and serving as a customer to councilors for their council results. The Caretaker role has moved from person to person every two to three years.
Personally, I’ve been on the Jedi Council since we formed it nearly 10 years ago. Over that time I’ve worked in nearly every role on the council, some of which I liked and/or was good at, and some I didn’t like or do as well at. The council structure has given me the chance to explore and grow (or I wouldn’t have stayed for 10 years!) That’s another benefit of the council approach—it lets councilors play to their strengths, and doesn’t rely on us being somehow able to find the Director of Engineering who’s strong in all areas (and incidentally, who would be a single point of failure).
Lest I paint too rosy a picture, let me point out some thorns. With many people involved in engineering leadership, a lot of communication amongst council members is necessary. Likewise, it’s not always obvious to an engineer who is the best councilor to go to for a particular issue. So it’s not always the most efficient approach, but we do believe it’s a very effective approach.
So, when we are looking for a “Director of Engineering” we are actually looking for a Technically-Capable Jedi Councilor and Project Lead. That just doesn’t sound as good in a job ad.