Smartly Leadership & Management

Engineering Manager Holly Gibson knows from experience that building a career in software development and leading an engineering team demand long-term perspective, continuous learning, and doing things that seem daunting at first.

A road less traveled into software development

Holly Gibson, now Engineering Manager at Smartly.io, didn’t come into software development through the usual path. She started her career as an IT specialist and a website coordinator at the university where she studied theology and web design. After a less than ideal experience trying out a PHP online course, she didn’t think she would ever build a career in software development. She didn’t abandon coding entirely, however, but continued in the field of website management and graphic design, and then transitioned to program management for a nonprofit working with the disabled community and wounded servicepeople.

A turning point in Holly’s career was an intensive three-month, 60-hours-per-week Ruby on Rails bootcamp, which she took on with only some HTML and CSS, and a little bit of JavaScript in her pocket at the time. “It was one of the hardest things I’ve ever done, the classes were arduous. But unlike the PHP class, this was a positive experience. I realized that hey, this is like solving puzzles! I love puzzles!” she reminisces. “What the bootcamp essentially taught me was problem-solving and how to teach myself to learn, to find my own answers. And that’s a useful skill in any job, particularly in programming.”

Take the driver’s seat of your development

Teaching yourself to code from scratch demands an intrinsic motivation and an almost dogged persistence. And taking an alternative route to a career in software development can make impostor syndrome an almost constant companion along the journey.

After the bootcamp, Holly landed a job in a small EdTech startup as the company’s first and only software developer. Talk about jumping into the deep end! “It was a crash course into all the different aspects of building and maintaining a web app for business. I had to learn a lot and very quickly about servers, databases, and APIs, just to keep the whole thing afloat,” Holly says. “Once the server got hacked while I was holidaying, and I had to rebuild the entire server in the middle of a forest. It was no laughing matter, and the experience taught me a lot, especially about how to keep calm, handle a crisis, ask for help, and trust my googling skills. My impostor syndrome abated a bit after I got us through the crisis.”

Owning your development doesn’t necessarily mean you have to go the full distance alone. “Finding mentors is particularly important for anyone who comes into the field through an alternative path. I frequented meetups to find people to talk to and learn from and ended up hiring one of my mentors to work alongside me at the EdTech startup. It was good to work with someone who was more experienced than me. I asked so many questions and tried to draw as much information out of him as possible to boost my learning”, Holly chuckles. “And I’ve tried to give back during my career, too. I ran a Women Who Code network back in Austin, scaling it from zero to 3000+ members. And I’ve coached other developers in the companies where I’ve worked, too. One of the junior developers gave me the nickname of fairy code mother.”

Do what terrifies you at first and be prepared to put in the work

After working in several companies ranging from startups to consultancies, Holly joined Smartly.io as a software engineer in mid-2019, jumping into a team that builds image and video templating tools that advertisers and creative professionals use to create engaging visuals for online advertising. “The team’s domain matched my interests nicely — I have some background in web and graphic design, and I see myself as part engineer, part artist. My role was front-end focused, which requires a lot of empathy and understanding towards the users, so we can build a powerful and enjoyable user experience”, Holly says.

In 1-1 discussions with her team lead at the time, Holly expressed a willingness to go down the engineering manager track. She had managed teams in her previous companies and had always enjoyed the human side of things, coaching and helping others. Smartly.io was growing fast, and new teams were being formed at a good pace. “As team lead positions opened up internally, my team lead asked me if I was going to apply, but at the time, I didn’t feel confident I could learn a new tech stack so fast, all the while taking care of the manager’s responsibilities. Back then, Smartly’s engineering managers acted as tech leads, too, and they needed to understand the tech stack deeply and be able to lead discussions on technology”, Holly says. “So my team lead asked me, ‘What do you need to become confident?'”

With her background being more front-end focused, Holly decided she needed to up her game in infrastructure technology. Development teams at Smartly.io are fullstack, which means that engineering managers need to be knowledgeable across the stack. Once again, Holly took the initiative in her development, made herself a learning plan, and found a class to level herself up in Kubernetes. Later on, the team she was working in had grown so much it needed splitting, and she decided to apply for the team lead position of the newly formed team. “I got the job and became a team lead although I was terrified at the opportunity. Most of the senior developers had stayed in the old team, so ours was quite junior and had an intense backlog. It wasn’t going to be a walk in the park for us.”

As a leader, focus on the long-term emotional health of your team

When she had applied for the team lead role, Holly had made a 90-day plan for the team. “I didn’t only focus on the outputs the team needed to deliver or the technical stuff. Instead, I included the team’s emotional health in the plans, too — how I could make the team a safe space and create a good team spirit”, she says. Good emotional health in a team is valuable in itself. When people feel good about their team and feel at ease with one another, it creates a good experience for everyone involved. It also carries long-term benefits for the team’s productivity and ability to succeed. When coworkers trust each other more and have a sense of psychological safety, their work flows more smoothly and they are more encouraged to try out new things and innovate.

“Later on, I took on another team that had a long background of personnel changes and their work had been deprioritized on the strategic roadmap. Team spirit was pretty low, some team members were very frustrated. As the new team lead, my first priority was to make them feel safe and stable again, instead of putting the outputs first”, Holly says. “I got to know them as people, learned their backgrounds, and asked how I could support them, and what their wishes for the future were. After a while, even those who had felt discouraged said they had started feeling better again. You can’t treat people as assets and expect them to be engaged, instead, you have to show you care about them, you prioritize their needs and show up for them.”

When a software developer becomes an engineering manager, a mindset shift needs to take place. You aren’t working with machines anymore, you’re working with human beings, and people require more flexibility. Your team members can go on sick leaves, study leaves, and parental leaves. Your tenured developers might apply for new positions, your new joiners may take time to ramp up. “Things are very fluid, and that may feel difficult at first if you are like me and you like to make good solid plans and stick to them,” Holly says. “My old mentor once told me that when leading a team, I have to be like water that flows around rocks. There will be surprises and obstacles, and your job is to make sure the team can flow around them.”

“For example, you don’t want your team to have lone geniuses who are the only experts on specific parts of the domain, because then you don’t have anyone to cover for them. While it can be tempting to let that one expert take care of things quickly, especially when you have pressure to deliver against deadlines, you’re really setting your team up for failure in the long term, because you aren’t giving anyone else the chance to learn,” Holly explains. ”Instead of focusing on quick wins in the short term, you need to see the team’s roadmap as a marathon, not a sprint — or a relay rather than an individual race.”

With so much change going on and surprises behind every turn, being in the front line as a team lead can get overwhelming. “Especially if you’re prone to overachieving, you have to be very honest with yourself about your capacity as well as that of your team,” Holly says. “Learn to prioritize — as not everything needs to be or even can be done right now, there are only so many things that fit within the team’s bandwidth at a time. Learn to delegate — for me that meant finding a lead engineer to take on some of the responsibility. And remember to manage up — if expectations for the team are too high, communicate it to your manager.”

Finally, Holly has a message of self-compassion for all the engineering leaders out there. “If you have high expectations for yourself, learn to be kind to yourself. In a fast-moving environment, it can be easy to fixate on the ever-growing to-do list. Instead of equating success with an empty to-do list, turn your gaze to what you and your team have already accomplished and feel a sense of accomplishment in that.”

We have to constantly adapt our ways of working and find new and better ways to operate in the fast-changing environment. It’s a process of creative destruction: old ways become obsolete, and new approaches are born out of new needs. In refreshing our engineering team’s working agreements, our mission has been to find the minimum level of coherence where we can function while allowing maximal autonomy to development teams. 

Emphasizing the autonomy of individual teams

Our engineering team consists of 13 full-stack development teams, each of which owns a particular product area. They enjoy a high level of independence that hasn’t changed over the years. The teams own their roadmap and are in charge of improving the technical solutions as well as managing the technical debt of their product area. They are equipped with frontend, backend, DevOps, product design, and product management skills which empowers them to develop their product area end-to-end. 

We have chosen to build full-stack teams instead of separating each of the different skill sets to their own groups, because it empowers self-organized ways of working. The development teams are autonomous units with their own products and they have the freedom and responsibility to build and improve those products in a sustainable way. In the past two years, we have improved the full-stack team structure by recruiting more product designers and product managers. There is now one product manager per team, and one product designer supports one to three teams on average. We have also been strengthening design thinking and giving product design a more central role in product development.  

Now that we have more than double the number of teams compared to two years ago, we have found that we need to find a more reasonable balance between what ways of working we standardize across teams and what teams can choose on their own. It’s not feasible to guide each team individually, so we have looked for ways to steer the whole ship in the same direction instead. 

Adding high-level philosophy 

The development teams have a lot of decision-making responsibility, and sometimes it may feel a little overwhelming. Adding layer of basic principles to the working agreements helps teams align their thinking with the general direction of the whole company. For example, one of our core principles is Collaboration over silos. We believe that generating a shared understanding is more valuable than the short term wins gained by solo projects. It also means that no part of the product development cycle should be a handover, but have a tight feedback loop between the agents performing the different steps.

While we allow development teams a lot of autonomy in choosing their ways of working, we want to be somewhat opinionated as to what are our preferred ways of building the product. Because one of our core principles is that we are here to solve our customers’ problems, we try to build minimum vertical solutions that produce value to our customers. We also want to push these solutions to production early on to get the feedback loop going, instead of trying to build massive releases that seek to do everything at once. At the same time, we don’t want to build features just for the sake of producing code, so we set clear expectations to the usage and measure if we meet those expectations.

Choosing what needs to be standardized and what doesn’t

The old working agreements didn’t make a clear distinction between binding rules and best practices that teams could either follow or discard. This ambiguity diluted the working agreements, so this time we paid extra attention to determining what we need to agree on the organizational level, and where each team can define their own approach. In short, we set out to find the best ratio of standardization and customization. 

Sharing information openly between teams is something we want to stick to regardless of the size of the engineering team. Transparency needs to be routine, and that’s why we have agreed to share meeting notes in our internal chat and tag them for easy retrieval. We have also agreed to track epics, stories, and bugs in JIRA to collect the information that all teams need access to into one organization-wide communication channel. However, for monitoring team-specific tasks, the development teams are free to choose their approach and tools. Some teams use JIRA for tasks too, while others use physical kanban boards and post-it notes. 

Clarifying roles and responsibilities 

As the organization is growing, we felt it was essential to clarify the different roles (developer, team lead, product designer, and product manager) and their responsibilities within the development teams. For example, a product designer is responsible for flagging usability issues in the team’s responsibility areas, and developers are responsible for technical solution design. 

Agreeing on responsibility areas on a high level doesn’t mean that they are chiseled in stone. Actually, we believe that in healthy teams, these activities are decentralized. For example, while the product manager is responsible for providing the customer perspective, everyone should have an understanding of customer needs in a well-functioning full-stack team. Similarly, the team lead is responsible for making sure the team works efficiently, but everyone should feel ownership of the team, raise issues, and help fix problems together. 

Autonomy is a defining characteristic of our way of working

Even though our product organization has grown significantly during the past two years, we want to stick to our end-to-end full-stack teams and mandate as little process as possible to increase team autonomy. Our teams own their roadmaps, make decisions on how to improve their product area, and choose how to implement those improvements. 

While our ways of working have evolved to support a larger team and a more complex product, they are still driven by largely the same principles as before. We are still on the mission to simplify things as much as possible, and avoid adding rules and processes for the sake of rules and processes.

The work is by no means finished. We still need to find new ways to support transparent communications across all the development teams, and steer clear from siloing. We also need to keep exploring the best ways to reduce dependencies between teams while at the same time setting up more platform-like teams that build solutions that other teams use. Even after we finish this round of refreshing the working agreements, we’ll need to keep a sharp eye on how well they support our evolving organization and reiterate them when needed.