Two years ago, I published an article titled “Tragedy of the Project Team” in Frankly Speaking, which was a slight vent on how project teams at Olin were operated. If you haven’t read that article, I do strongly recommend it for context to the following. The article served as the framework for how I approached team leadership during my time as PM/lead on AERO and Rocketry, and it has been quoted back to me by future leads who have bought into its conclusions. In one unique instance, a sophomore told me that the article made him decide to come to Olin to co-create that kind of future. I am honored by the support I have received and Oliners’ eagerness to co-create, but I want to explore that article’s pitfalls by teaching you what I’ve learnt in the past two years about how to build a team and a culture.

How can a company with a small name, competitive-yet-not-extravagant compensation, and greater-than-average volatility to market performance attract and maintain top-notch employees? This is what I was asking myself this summer while I worked at Second Order Effects, a small engineering services firm based out of LA. The employees (and founders) had stacked resumes including SpaceX, Google, and the rest of Big Aerospace and FAANG. These phenomenal engineers had no shortage of opportunities, yet they came to SOE, they stayed, and they rated it well on Glassdoor. The company had amazing culture and morale, teams that executed in harmony, and a respect for the individuality and humanity of its employees. I think we can learn a lot from SOE and apply it back to Olin project teams to understand retention and loyalty precisely because SOE has to rely heavily on team culture to survive in a world of Goliaths. 

SOE has something I haven’t seen on Olin’s project teams or seen executed properly at other companies I’ve worked at—people management. Oftentimes this role is folded into engineering management, so you don’t see it advertised, but you can always feel its effects. Let’s talk about some definitions. Project management, which you all are familiar with, is making sure deadlines are met, budgets are kept, and quality is assured. People management is about managing team dynamics and hiring, career growth and development, and creating a team/company vision. Project managers become senior project managers, people managers become CTOs. Both of these are critical roles for any team—at SOE, like many firms, they’re kept separate. Each project has an assigned project manager and each employee has a direct mentor/manager that does the people management. Lower-level managers balance managerial duties and day-to-day engineering, while higher-level managers do only mentorship/management.

Having strong people management is the key to a better culture and reduced turnover—it creates lasting loyalty between the team and the individual and vice versa. At Olin you often hear project teams leading with their projects; contrastingly, you rarely hear them lead with a people-before-project focus. In this article I will dive into five factors of people management I learned from SOE: team bonding, learning opportunities, mentorship, goal setting, and reflection. Then, I will focus on how we can improve in these areas without changing our team structures or adding significant work for our leads. Even tiny shifts in the ways we think about our teams can make a huge impact.

At Olin we do a good job with team bonding; unfortunately, we often look to it as a one-size-fits-all Band-Aid for our other problems. While it can support social cohesion on a team, it does not tackle structural issues or promote behaviors that drive loyalty. While team bonding is critical at companies and larger schools, Olin’s small size reduces its efficacy by eliminating two major value propositions: networking and friendship. At a larger school, you won’t have these same people in your classes, projects, and the dining hall—so team bonding builds strong friendships and expands your professional network. At Olin, project teams don’t have to position themselves to be friend groups—attempting to force that is time better spent on the other factors.

The second factor, learning opportunities, is where I need to discuss my conclusions from “Tragedy of the Project Team.” I had claimed that the solution to member retention and interest boiled down to novel projects, more engineering freedom, and less structure. I have seen this in action; SOE as a services firm has rotating projects and these novel projects can spur co-learning amongst engineers across all levels. But in the article, this was mistakenly presented as the sole factor; I was reflecting on what I thought motivated me and gave me purpose. At Olin, I think we can still improve on project novelty and rotation, but this is no longer my main concern regarding our teams’ health.

The third factor is mentorship. This is the chicken-and-egg problem of project teams; mentorship supports retention, and retention creates mentors. A team needs to provide strong mentorship across all fields from technical to operational. Right now, this is the factor that scares me, seeing that in my time at Olin we have had a massive upperclassman exodus from project teams and now have almost ubiquitously sophomore leads. In order to improve here, we need access to upperclassmen who give mini lectures, explanations at whiteboards, and tutorials. While this necessitates focusing less on their own projects, mentorship should be considered desirable, especially for the type of engineers Olin attracts. Teaching and leadership are both rewarding experiences that make for well-rounded engineers. Often these come with learnings of their own; for instance, teaching can help foster a deeper understanding of the subject and allow for exploration of new ideas. How do we jumpstart our way out of this Catch-22? I hope that by focusing on the remaining factors, a stronger team culture and loyalty will emerge, and in turn naturally grow mentors from within.

The fourth factor is goal setting, which is critical to career and technical development. This involves a difficult, but pivotal decision: put people over projects. A team should assign tasks and deliverables based on individual goals and create new projects off the critical path if necessary. It should not sacrifice a person’s goals for timeline or to fit to a Gantt chart—especially those of new members. Loyal members will pay it back by occasionally doing tasks which do not align with their goals, but a new member given an arbitrary task will simply leave and never feel any loyalty. At SOE, I clearly outlined my goals to learn Altium over the summer and when a quick-turn project from a client came through, I was assigned to it despite never having used the software. My coworkers respected my autonomy and never got involved beyond reviewing my work. Did the schedule slip slightly? Yes. Did the final product have some minor issues and inaccuracies? Yes. But do they now have a skilled employee who can operate independently and is loyal to the team? YES. Investing in your people builds a strong set of dedicated future engineers, leaders, and team-builders. 

Lastly, we have perhaps the most important factor: reflection by design. As humans we suck at being optimistic, and we also suck at remembering what has happened (side note: this is why we all should write gratitude journals). Reflecting on learning highlights the value and growth in the experience, reflecting on goals better directs personal focus, and reflecting on areas of improvement creates space to act upon growth opportunities in a safe environment.

So how can our teams focus on these factors with minimal extra effort? First, we can implement regular 15-minute meetings between each member and mentors, keeping in mind that mentors should be different from one’s subteam lead and generally not PM. One-on-ones are opportunities for reflection, goal-setting, and feedback both for the team and for the member. This article is too short to go into the art of running one-on-ones—contact me to learn more. Members should be empowered to set varied goals across: domain-specific technical learning, cross-disciplinary skills that make for well-rounded engineers, soft skills, networking, etc. Members should be required to brainstorm and work towards 4-6 concurrent goals, refreshed and updated as they are completed or need changes throughout the year. Importantly, their tasking should reflect these goals, not a Gantt chart. Next, we can focus on making learning opportunities more explicit, obvious, and efficient through mini-lectures at the start of meetings. This can give people the guarantee that they will learn something new every time. These could be as little effort as 15-minute brain dumps about whatever one of the leads finds cool and insightful (even if completely irrelevant to the team’s project, such as a LinkedIn workshop). If nothing comes to mind, try polling members about blockers on their projects and expand on those as a team. Need help getting a loft working? Continue that CAD tutorial with a lecture on swept bodies and guide curves. Consequently, this reduces open work time at meetings—we should embrace this and prioritize learning and planning over unstructured work time. In a team with strong people management and loyalty, work is mostly done outside of meetings and blockers are resolved impromptu by sending an Outlook invite or DM to relevant resources like a coworking group or leads. Hence, this should not be viewed as a sacrifice, but an investment. Lastly, we can provide notebooks/journals for members and encourage note-taking during lectures and research/project work. These can be filled front-back technically and back-front with goals and reflections. This can ground learning in a quantitative medium. All of the above suggestions are low-effort for the leadership team, but are incredibly impactful to the overall team culture.

I hope that this article serves to highlight some of the ways in which we can think differently about team-building and team culture on project teams, and perhaps Olin in general. I have explained why factors like team bonding play a minimal role and how factors like learning opportunities, mentorship, goal setting, and reflection need to be more thoughtfully engaged with. I don’t believe Olin project teams have ever had a people manager (AKA engineering people manager or engineering manager) and it shows. Recently, our project teams have dwindled due to factors within our control such as culture, and factors outside our control such as difficulty fundraising, problematic space allocations, and time-consuming safety audits. It is now more important than ever to turn our focus inward as project team leadership. To ride out these external turmoils we need people and cohesion more than ever. Thankfully, those are outcomes we can influence directly when we put our minds and hearts into those around us. Even if it means making sacrifices elsewhere on timelines, scope, complexity, etc., start being people-obsessed, not project-obsessed, and slowly, success shall blossom.