After marking 3 years in a high-paced startup with a very ambitious goal, which unfortunately had to shift gears, I wanted to summarize my experience and the learnings I accumulated in some areas throughout this journey as a software engineer. This is basically a note to my future self so that I can revisit as I’m growing and learning more about people and business. I thought about sharing this publicly as there might be some areas which readers might find insightful.
I wanted to split this post into five areas which I believe played a critical role for me in navigating and succeeding in such an environment:
Speed and value creation play a significant role in the success of startups as these components are heavily associated with the viability of the company. Being an individual that delivers consistently and incrementally helps the company achieve viability and to the very least helps the company build trust in its workforce. In practice, delivering consistently requires a combination of conditions to be met like good mood, a day-to-day life without blockers, fast and easy to use internal tooling, autonomy, but most importantly a vision about what your team should achieve and ideally tangible steps to get to the envisioned outcome.
Having that vision even vaguely defined helps engineers produce value incrementally. This can be done through different means like writing and reviewing code and design documents, resolving incidents in production and documenting fixes and learnings, assisting colleagues with challenges that they face. As long as these actions contribute to the long term vision and bring value to the table, one helps the broader team and the company achieve its goals.
A good technique that helped me track my achievements, keep focus and deliver consistently is keeping a log that I populate on a weekly basis. At the end of each month, I revisit what I have achieved in the last month and try to make a story out of it. I try to understand if these achievements contributed in some way to the broader vision. I try to get unofficial, quick and dirty feedback from my peers and continue to iterate towards achieving things that contribute to the broader vision. Celebrating any achievement helped me keep the momentum! Even if those didn’t contribute to the broader vision as much as I would expect, I still learned something from those.
In order to populate the log on a weekly basis, I had to achieve small tasks. Splitting big projects into smaller tasks is crucial to achieve incremental value delivery and completion of the project. The splitting part is something that engineers usually have the autonomy to do in startups and the more experienced one gets, the easier it becomes to split the projects into smaller tasks that bring value. In addition, splitting into small logical tasks helps greatly with prioritization and planning. For example, I prioritize tasks that bring the value that is expected from the project and later implement tasks that enhance the maintainability, robustness and other aspects of the system. The splitting part is also a good exercise to understand how much effort it would take to achieve the whole project.
Speed usually comes with a couple of drawbacks like reduced communication, technical debt, work duplication and higher probability of taking non-data driven decisions. It’s very easy to fall into the trap of “delivering value no matter what” and it should be a responsibility of each experienced leader to observe occasions where things could be done in a better way in a similar amount of time and proactively communicate that with their peers whenever possible without risking sidetracking them and breaking the momentum. However, it’s also easy to fall into the trap of “building things the right way” and delaying value delivery and I believe that this is a much bigger risk for startups to take than technical debt that could potentially be fixed later (as long as it can be fixed later).
In my opinion there is no definitive answer to the above, there are pros and cons to both approaches. I believe that a balance between the two approaches is what works in practice. At the end of the day, it’s better to have something rather than nothing. Having been part of such an environment with all these drawbacks, I have identified one particular component that I believe is very important in reducing the impact of these drawbacks. This is communication.
At some point, my team built a platform that other teams had to onboard so that we can get the value of this project. This was the period I learned the most about how different teams operated, their goals, their priorities and what they’ve built. That was the time I understood that clear communication and continuous syncs with our customers (= engineering teams within the company) were very important to ensure that we build together and we reduce the impact of the drawbacks mentioned above. Among others, we were participating in their design documents, we were asking them to bring feature requests to our team, we were promoting patterns that other customers use instead of building new patterns that may bring little benefit, but more complexity.
All these actions helped us minimize work duplication, reduce technical debt and build consistently while maintaining speed as much as possible. I’m pretty sure that there are other components that played a role in reducing the chaos and inconsistency that I possibly didn’t identify, but from my point of view, communication was a very important bit. Communication also helped us build the right thing for our customers as we managed to remove a lot of overhead from them by enabling functionalities that they wanted without dealing with the complexity of those.
At some point in my career, a person that I admire gave me the advice that I should be building a network of people to be able to achieve my goals and influence people. Since then, I have tried to do that.
I joined this startup during COVID-19 through an acquisition and my whole team was based in the US. Building such a network had a higher degree of difficulty given the circumstances and the fact that it took me almost 2 years to meet in person the colleagues I have collaborated with daily. However, the circumstances were similar for my counterparts as a lot of my colleagues joined around that time. It felt to me that we were all keen to know each other better and work as a team.
I think that the curiosity to meet my counterparts in conjunction with being open to discover and accept different cultures were the main personal drivers that helped me build such a network across EU and US with people in and out of my team. In addition to my personal drivers, there were other factors, aside from the willingness of each individual to build relationships which is probably one of the most important things, that I believe contributed to that those are:
To be honest, the way I used to build most of my network in the early days was by leveraging my technical skills. It felt more natural as the nature of the work I was doing was heavily technical at that point. However, I could do even better by participating in other activities to help expand my network faster. As I grew within the company, expanding the network became much easier and required less effort.
Building a network can be a satisfying activity as one gets to meet different people and cultures and sometimes build strong relationships with them that go beyond the context of work. In addition to that, in the business context, having a network is a powerful tool that brings a lot of benefits and should be used diligently and for a good cause. It can, among others, greatly accelerate development speed, since one knows where to ask questions, and help receive fast feedback and buy-in for cross functional projects. It also helps with reducing chaos and inconsistency within the organization since communication is much easier and more direct.
A very important aspect that helped me navigate in such a high-paced startup was to be able to align with leaders and be able to influence people around me. A common characteristic of a successful leader is the ability to scale themselves. To do so, leaders have to build trust with their colleagues, clearly communicate their vision, make them understand the value their vision will bring and influence them to contribute towards that vision. When done right, the team acts like a value delivery machine. To achieve that, it requires mutual effort by the leads and their teammates.
To align with and build good relationships with leaders, I found it important to be open to receive and incorporate feedback while standing by my values. Leaders may be more experienced in this so they might be able to spot things that can be improved more easily. In addition, being transparent, data driven on decisions and vocal when I have questions or concerns are things that helped me build trust and reduce the cognitive load when communicating and aligning with my leaders.
Having said that though, following the vision that a leader has doesn’t mean that you can’t come up with your own vision on how, for example, a particular system should be built. It’s rarely the case that high level leaders will dictate how exactly value will be delivered, they usually just focus on what value must be delivered. Then each organization and team comes up with their own strategy on how to bring that value to the table by splitting the big goal into smaller goals as previously mentioned. In some cases, these organizations and teams even have the power to define what value they should be bringing to the table by pitching ideas and influencing their leaders.
As a leader, what helped me influence people to follow my vision, aside from pitching the vision to them and building trust, was to lead by example. This term has different meanings for each organization, individual and level of operation, but for me it means to take ownership, be there for your people, be consistent in delivering incremental value by producing and reviewing design documents and code, provide rich documentation so that teammates can look back months later, communicate proactively and effectively and in general follow the team operating rules (e.g. PR guidelines, definition of done for projects, etc) whenever contributing at the team level. In addition, what also helped me influence people was sponsoring difficult projects, helping them as needed, letting them lead the effort and make mistakes, motivate them and celebrate their achievements.
Sharing knowledge is a very important activity for teams to learn faster, save time and avoid repeating past mistakes. In addition, it helps build your network faster. I heavily invested in that area throughout my tenure so far as I saw that people appreciated that and started using similar techniques to share knowledge as well which helped me learn more from their experiences. Furthermore, I learned a lot from sharing knowledge with others as there were several cases where people made me explore more with their questions.
In particular, the way I shared knowledge was through different means that include:
Sharing knowledge can be time consuming, especially the side chats that can pop up at any time and in which the information is not persisted, therefore I had to timebox this activity to ensure that I have time to focus on the rest of my goals. I found that documenting decisions with their rational, common questions and answers, patterns and strange behaviors of systems greatly helps with saving time as I can usually share a link to give an answer to someone who asks and be able to look back to that content at any time without using too much of my brain power trying to remember all this information.
In a fast paced environment, it comes very handy to be able to open the documentation tool and find an answer to a question that you originally answered but no longer remember due to reasons like constant high rate of context switching or simply rare use of the topic in question.
What helped me deliver good (?) documentation compared to the time I invested on writing such documentation, was to focus on writing in a way that is understandable to the target audience. For example, for design documents where the audience consists of engineers, I would avoid explaining what Kubernetes is. For documents that were targeting non engineering functions, I would avoid mentioning Kubernetes at all.
Documenting is not a panacea though and should be balanced like any other aspect of day-to-day life. A significant amount of time can go into documentation, sometimes over documenting things and making them look more complex than they really are. There are always people who understand what I have written and others who don’t, who usually need some further clarifications, and this is fine in my opinion as the day-to-day work life of an engineer includes more activities than just documenting.
To summarize, sharing knowledge in any form helped me learn more from and about others, brainstorm and grow people around me, indirectly bringing value to the company.