Learning to Manage Projects as an Engineer
About a year ago I shifted from working at an large, enterprise organization with hundreds of other engineers to working at Singularity Energy which currently has 9 employees total. When I first started here, I was expecting new responsibilities since there were far fewer employees. I expected to wear several different hats, and to be working in new areas that I had little exposure to before.
These expectations and assumptions about what working at a startup would look like were quickly discarded once I started working at here. I was hired as an engineer and I was expected to do engineering work. However, things were still quite different than my old work environment. Many of the structures that surrounded scoping and planning have been trimmed down to their bare bones, and the responsibility of scoping, estimating, and planning has shifted more into the hands of the engineers and engineering lead working on a given project. This shift in work environment meant that I needed to quickly gain new skills and ways of working to meet the increased autonomy that I had been given. Here are some of the key learnings and tips I have found during my ongoing work to become an engineer who thrives in the startup environment.
Tools for Tracking are a Must
Singularity’s tool of choice for doing project management work is Google Sheets. The organization uses Sheets to track engineers time against each of the projects that we are currently working on as well as to highlight key dates and deadlines that the organization is tracking.
This top-level view of the work being done at the company worked well for me during my early time here, but as I’ve grown to take on more ownership over the projects I work on I have found that I need far more places to track the specific work being done on the projects I contribute to. I’m currently working on a large-scope, long-term project for Singularity that has further exposed me to the need for tracking and project management. A question like “are we on pace to deliver this product in X months?” is almost impossible to answer if there isn’t quantifiable data showing how far along the project is and what remains to be done.
In practice, this means tracking my own work and projects at a more granular and in-depth level than before. A foundational piece of this more granular tracking has been a large Google Sheet with rows tracking individual milestones for the project. Similar to a Gantt chart, time can be allocated against each milestone and we can track our progress against what has been allocated. The spreadsheet currently has 93 rows tracking individual milestones, it would be near impossible to have a similar top-level view of the project without the team taking the time to create and maintain this spreadsheet. It takes us perhaps an hour a week to go through and update the spreadsheet and I think it gives us plenty of value for the investment.
Planing and Scoping the Right Way
In my prior experience working at a much larger company, the scale of planning I was responsible for was at the team level. This meant that tasks like estimating the time a ticket would take were quite familiar to me, while tasks like allocating resources against a project and tracking deliverables on a timeline were handled by managers. These higher level aspects of planning have been critically important during my time at Singularity and I’ve had to learn how to do this kind of planning as an engineer.
The first step for my small team when starting a new project was to determine a long list of tasks to be done and to assign pessimistic estimates to them. This large backlog of tasks that we created together largely became the rows in the spreadsheet mentioned above. During this planning process, I was reminded by my teammates of the importance of giving pessimistic estimates. Problems should be expected, and even the best team of engineers will come across tasks that challenge them in unexpected ways.
The other key planning step that my small team took early on was to identify any known unknowns and unknown unknowns. There were many unknown unknowns for us when we started the project, and flagging them early allowed us to prioritize gaining the understanding and insight we needed. Weather through information gathering calls with the client or doing research on our own, the end result is that we have now turned several of our unknowns into know problems that we are ready to solve.
We’re All in This Together
I’ve worked on teams with other engineers for my entire career. I’m used to asking questions when I’m confused, and used to leaning on each other for support when needed. What has changed as I have shifted to a smaller work environment is that we have more projects to work on than engineers. The most common way of working at Singularity is for one or two engineers to be on a given project at a time. Without a small team of engineers working on a project, the task of ensuring a project will be delivered on time falls to the one or two engineers working on the project.
This shift in responsibility and increase in autonomy was hard for me to manage at first. The tools and strategies mentioned in the above sections have helped me to improve and become the more autonomous developer that a small start up needs. However, I think the most helpful learning I’ve had in this area has been understanding that I can ask teammates to take things off my plate when I know I’m not going to get to them in time. I feel lucky to work in an environment where this is the case, where the prevailing mentality is that we are a team working together towards a common goal. Identifying the tasks that are likely to miss their deadline and asking for someone to help you with them is a good thing. It took me some time to recognize that if I am expected to lead and help manage engineering projects, that also means asking for additional resources when they are needed.
I hope this is helpful for other engineers making the switch to a small company. I’ve really enjoyed learning how to operate in a new environment and can feel myself growing each month. I’m interested to hear how this change has gone for others and what other tips for project tracking I might have missed. Feel free to reach out and share your experience.
