Leading Projects at Galois

Hi there, my name is Matt LeBeau, and I have been a Project Lead at Galois since May of 2020.  Today, I want to share some of the ways in which my career experience in commercial software development prior to joining Galois has helped me to see success at Galois in the Project Lead role and where I had growth opportunities as I moved into this role.

My first read of the Project Lead role almost caused me to ignore the recruiter inquiry, based on the role title and the fact that I’d have no direct reports. It sounded like a Project Manager role in commercial software development, which I wasn’t particularly interested in. My concern was that Galois would represent a career slip, my technology skills would not be well-utilized, and that my opportunities for growth would be minimal and unaligned with my intended career progression. That said, Galois’s unique implementation of the Collaborative Web, coupled with a deep set of technologies to learn into/about, led me to curiosity regarding exactly how it worked in practice. The only real cost to me to satisfy this curiosity was a day of interviewing, so I proceeded. My curiosity continued to be piqued, so here we are today.

In a way, I’m writing this post to myself in early 2020, as it attempts to answer a number of questions that I had when evaluating the opportunity for the Project Lead role at Galois against other offers in commercial software leadership. Galois is an unusual organization in many ways. I won’t go over the implementation of the Collaborative Web that we practice in detail. Still, I will mention some aspects of our organizational structure that contribute to how the Project Lead role at Galois is different from other technology engineering leadership roles.  Specifically, I’ll outline how Galois’s Project Lead role compares to the Engineering Manager roles that I’ve previously held in other technology-producing organizations.

What does a Project Lead do precisely?

Prior to joining Galois as a Project Lead, I held software engineering roles for over a decade, as well as engineering leadership roles for a similar amount of time, and the very first thing that surprised me about Galois was the fact that, as a Project Lead, I would have zero direct reports.  The key piece to understand is that as a Project Lead, the engineers on my project are fully accountable to me for their results on my project. So while I lead an engineering team and attend to engineer’s success on my projects, I am not solely accountable for an engineer’s career path or results success across their portfolio of projects – as I would be in a traditional “Engineering Manager” role. This is a subtle but important distinction as it gives a correct orientation to how labor commitments are recruited for and delivered upon within Galois.  For attending to things like career progression and results across a portfolio of projects for a given engineer, I am partnered with another Galois resource that each engineer is assigned. Together we deliver on that engineering support.

In practice, not having direct reports is…pretty comfortable, actually. I am still responsible for recruiting and hiring (though typically from an internal pool of engineers), dismissals from the project, for the success of the project, for client interactions, for liaising with other engineering teams internal to Galois and with our partners and collaborators, for writing reviews, for managing subcontractors, for helping build engineer careers in the context of meeting project deliverables, for driving to concrete requirements with clients, for project tasking and release management, and so forth. In other words – a lot of the things that I was doing when I had direct reports in previous roles.

The key difference here is that all of the engineers on my teams are “there by choice,” meaning Galois provides the freedom for people to opt into and out of work on particular projects.  Essentially, engineers make time-limited “offers” to me to “perform” on my projects, and we negotiate and formalize conditions that meet the needs and interests of both myself (and thus our client) as well as the engineers themselves. Providing this agency to people, coupled with an absence of organizational hierarchy, means that a significant predictor of my success in the role is my ability to work collaboratively with others such that they prefer to work with me and on my projects.  It strongly encourages me to think about how a given role will benefit a client and how it will feed the interests or growth of engineers on the project. Conversely, it strongly encourages engineers to actively and continually consider where they are putting their time and energies and if that aligns with their goals, plus an ability to make changes to suit their needs without being required to go to the external job market.  

Additionally, engineers at Galois often (by choice!) become involved in scoping and proposing work to clients that align with their research interests. They can have direct influence on the sorts of projects available to them to opt into. Of course, without careful tending, this arrangement could unintentionally result in pitting Project Leads against one another.  As we’re all pulling from the same labor resource pool, the possibility of resource contentions exists and must be managed collaboratively across Project Leads. We balance allocations taking into account client need and timeline, engineer growth, and the perception of Galois in the marketplace. There’s a lot more to say about that topic. It influences many areas of execution across the organization, so our intentionality with regard to selecting suitable candidates and helping to prepare them for this sort of organizational-level problem solving deserves a more complete examination than I have space for here.

There’s a type of double-jeopardy that is embedded into how we work together that, if I may don a somewhat nerdy hat for a moment, can be thought of as a human-driven machine learning algorithm. Specifically, engineers are training on what it’s like to work with different Project Leads and on different projects, and the realized benefits of each. Project Leads are, in turn,  training on how different engineers show up on projects and the skills that they bring to the team.  Given the “there by choice” nature of our internal labor economy, there are frequent opportunities to assess value and make changes to optimize for realized value. Over time (human time, not CPU time), Project Leads who perform well for their client and the engineers on their team provide training data for the Galois engineering community to assess which projects and leads are aligned with their needs. As part of the team, engineers who perform well against project deliverables are providing training data for the Galois Project Lead community regarding which engineers they may wish to work with going forward and which project areas they will opt into. In this way, Project Lead success at Galois comes easier to those who are comfortable practicing Servant Leadership. On the engineers’ side of the equation, skills in effectively collaborating with Servant Leaders, the ability to make and meet commitments, and the various research domains we work in are all factored into their decisions on where to make offers to Project Leads to work on their projects.

There are several “feeder roles” that we look for when considering candidates for the Project Lead role at Galois. As we are often pulling talent for this role from the commercial software development industry, we tend to hire people who have held previous roles like VP/Director of Engineering, Engineering Manager, Technical Product Manager, and, assuming a sufficient technical background, Project Manager.

So, let’s talk about some things my previous engineering leadership roles in the commercial software development space did not prepare me for as I came into Galois.  

Full Budget Control

I held a number of Engineering Manager positions prior to Galois. One of the key things that I did not previously have a lot of experience in was direct budget control for a project.  Sure, I was aware of budgets and was quite comfortable managing subsets of a project’s budget for my specific needs (typically, determining headcount, purchasing licenses for tools, libraries, and services, hiring subcontractors, and the like.) At Galois, in the Project Lead role, I am fully accountable for the project’s budget from start to completion and delivery.  As our projects are often research-focused and funded by entities like DARPA, they tend to have research goals, publication goals, and deliverable goals, which must all be accounted for in budgeting. Additionally, they will typically have a specific duration and phasing that is asserted at the project’s start. This was a contrast to my experience on commercial software development projects. We didn’t typically have such concrete constraints on dates (and often had far more specific requirements at project start.) Learning and growth regarding budget management and responsibilities were some of the pieces that attracted me to Galois. I’m happy to say that I’ve had the chance to learn budget management skills at a wider scope than I’d previously experienced, whilst strongly supported by other Galois Project Leads more familiar with the practice.

Research project scoping and assessment of progress

Another area worth covering here is the difference between scoping and assessing progress on research-focused projects compared to doing the same against commercial-focused projects.  As mentioned previously, our projects are often funded by entities like DARPA. DARPA is frequently seeking to invest in computer science research for questions to which we are not certain there is a possible answer. That took some adjusting for me. My experience in commercial software development led me towards tools for assessing and organizing projects that focused on techniques like setting sprint goals, timeboxing activities with poorly-understood value or path forward, and rapid and iterative pushes of software to production environments.  We used these tools to de-risk activities for which there was a critical mass of uncertainty.  

Research project leadership is somewhat different and requires a different approach (though you can still use a bunch of the tools that you’ve built up!) Specifically, I’ve learned to be more comfortable with uncertainty, to understand how to extract more client value from explored paths that didn’t yield the desired results by analyzing the data captured during experiments to prove or disprove a hypothesis, and how to work with research engineers to set concrete goals and a shared understanding of progress and value.

Galois is most often engaged to investigate specific computer science research areas of interest. The products of our work tend toward being either research prototypes or integrated systems that depend upon the research and tools/frameworks. Our projects often have nothing resembling a Production and Staging environment to deploy to. This too took some learning for me to let go of a variety of practices regarding maintaining Production quality and providing rapid response plans for unplanned downtime. I’ll admit that on my first Galois project, I cajoled the team into agreeing to an on-call schedule whilst an externally-facing portion of the program was executing. The team humored me and didn’t even tease me about it when we ended the project with exactly zero use of the on-call setup I’d pushed for.  Live and learn, right?

Imposter syndrome re: computer science research

Galois is focused on a number of very technical domains and is usually working on the bleeding edge of the bleeding edge of research. As a result, it can be intimidating to join the organization as an engineering lead.  Within commercial engineering leadership, we’re accustomed to having a basic technical understanding of how things function on Day 0 of employment and rapidly moving to a deeper understanding and command of the areas we’re responsible for within the first few months. As an example of how Galois is unusual in this regard, consider our work on cryptography libraries. Most engineers are familiar with using crypto libraries in their work and, in the same breath, are counseled to never attempt your own crypto implementation but to leave it to the unnamed “experts.” Galois is full of cryptography domain experts.  So, you can expect your Imposter Syndrome to flare up mightily when taking on a Project Lead role, regardless of the depth of your technical background. I had a colleague warn me early on not to expect to achieve technical depth in most of our research areas for a much longer time than I was used to in previous organizations. He was 100% correct in this assertion. This aspect of Galois, assuming that you can tamp down the Imposter Syndrome voices in the back of your mind, is one of the most rewarding with regard to career growth. Organizationally, Galois has a keen understanding for this common challenge to new Project Leads. They have invested a significant amount of thought and planning towards providing varied and wide support structures to help new team members blossom. This support is expressed in several complementary ways such that, at any given time, I have at least 2-3 options of supporting people for seeking to triangulate advice from and to lean on to gain an authentic assessment of my progress compared to expectations. The range and depth of learning that I get to do in the context of my job is immensely satisfying, and the environment in which I’m doing that learning is friendly, supportive, and regularly adapts to meet me where I am, technically. It’s easy to envision continuing to grow and learn in this fashion for quite some time, and my explorations on average tenure at Galois versus my previous employers bear out that vision nicely.  

On the other hand, as mentioned above, qualified candidates for the Project Lead role often have a rich background in delivering product to market and thus bring more sophisticated project management techniques and practices to our projects. There is a balance to be achieved here between allowing for sufficient schedule flexibility to pursue research goals while making certain that progress is demonstrable and that the examination of the research space is done in a disciplined and repeatable manner. I have found that this is a key place where I am able to bring my experience in running projects in commercial industry into Galois, and I’m pleased to say that the team here is both interested in and open to new mechanisms, tools, and practices for achieving a clear and predictable set of outcomes for our research.

Path forward for career

One of my main concerns when considering Galois’s offer of the Project Lead role was understanding where and how I would be able to frame my experiences at Galois in the context of my future career. I needed to be mindful of what a move from a well-understood role in industry like “Engineering Manager” to this “Project Lead” role would read as on my CV to potential future employers. Would it look like I’d had a steady progression of roles and responsibilities and then suddenly took on a much less influential role, and would that preclude me from consideration for roles that I was actually qualified for?

I’m happy to say that my concerns in this regard are erased now, based upon what I’ve experienced these past 18 or so months. The skills that I’m acquiring in this role regarding higher-level business management activities, like budgeting, contracting, and collaborating well across organizations, as well as a significant expansion of my technical depth and exposure to bleeding-edge computer science research, has given me confidence that I will be a very attractive candidate for roles in the future which would represent further career progression for me.  

With regard to personal growth and opportunities to get involved in new and exciting technology at an early stage, I expect that Galois will continue to be a rich vein to mine for the foreseeable future. I have confidence that many of the projects and technologies that I work on today are precursors to work that will see broad mainstream computer science adoption over the next decade. At the same time, I don’t feel like I’ve had to choose a specific technology or approach to specialize in, given that I’m typically leading several projects at any given time, and each is in a very distinct technical area. Continued technical growth is important to me as an engineer and as a leader of engineering teams. Galois provides that in spades, which is one of the key reasons I can see myself proceeding with career advancement at Galois for some time ahead.

Conclusion

My goal today was to help answer some of the questions I had when I was considering this role at Galois. Hopefully, I’ve achieved that!  If not, please feel free to reach out to me at mattl@galois.com. I’d be happy to answer any questions you might have!

Galois is a unique organization, and it specifically optimizes for a particularly considered culture and set of results. My native leadership style is very much as a servant leader, and thus it has been a great fit for me. If you’re of a like mind and practice, I’d strongly encourage you to explore roles with Galois. I believe you’ll find it refreshing and exciting!