Welcome to Incidentally, Allma’s publication. We interview engineering and reliability leaders, founders, and makers on the secrets and tools they use to scale their systems and teams. We share incident collaboration stories and learnings, in solidarity and with openness. Our goal is actionable for you to implement and high-level to be applicable; your feedback is always sought.
Scaling skills and teams is hard work, learn about Jackie's journey and insights along the way
From elementary education, to chocolate, to...tech?
Hi, I’m Jackie Wegman. I have a degree in elementary education because I have always been good with people, and teaching was great for applying people skills while also working with tiny people and adults. When I graduated in 2011, there were no jobs for a new teacher fresh out of school, so I bounced around to a few different temporary jobs. I eventually landed at Lindt as an inventory manager for a bit because it provided a salary, benefits, and I got a bunch of free chocolate along the way. A dream come true, right?
As fun as the job as Lindt was, I knew this wasn't my passion. That’s when a friend of mine who worked at Dyn said they were looking to hire someone for an admin position, so I applied and got an interview. I was very nervous going in because they were throwing words like “agile” and “stack” at me, which are words that I understood but that I never knew within this tech-based context. I had an interview with Andrew Sullivan, who basically invented DNS, and it turned out he was looking specifically for someone with people skills. I ended up getting the role based on my skill set even though I didn’t know anything about project management at the time. Luckily they were willing to train me. I learned that project management and agile were similar to a lot of teaching concepts with new names on them, so I was able to adapt quickly.
Bringing new skills to the table
One of the biggest things I learned at Dyn in those initial days was that my skills were still valuable in that space even though I didn’t have much confidence as a 26-year-old who hadn’t worked in tech before. One of the things I had from my teaching background that transferred well to my time at Dyn was how to influence people without needing to have authority over them. You can’t punish little kids and make them feel bad, you need to be positive and keep them feeling like they can move forward even if they stumble. This translates well in the software development world; having someone who can be there to tell you it’s okay to mess up and not dole out consequences at the end of the day is important for fostering a healthy workplace. I’m not going to make you fear for your job, I’m just going to make you feel like you still want to work hard and get things done.
Another aspect of working as a project manager and being the go-between for two different teams involved looking past the face value of someone's statements if they were venting and, instead, pulling out what's bothering them. What are the things that actually need to be escalated? I’ve been told I’m a good listener, so I am used to being on the receiving end of the thoughts, frustrations, and ideas that are an important part of processing problems. My job involved taking those sentiments and distilling them down into something actionable. It’s about mitigating both sides and acting diplomatically as a neutral third party so that things get done and issues can be resolved through better communication.
Going from a few hundred to a few hundred thousand people: from Dyn to Oracle
In my time at Dyn, we scaled from about 150 to 450 people. It was the kind of scale that felt massive... until Oracle acquired the company. When that acquisition happened, I was the IT Manager so I was in charge of migrating all of the Dyn systems into the Oracle systems. It wasn’t as much about scaling as it was about making sure people understood why certain changes were happening or admitting that we did not know why this, that, or the other thing was occurring. It was all about making sure the process was as easy as possible and everyone knew what was expected of them while moving over to Oracle.
From a customer-centric point of view, we were going from a 400 person company to a 140,000 person company, so we had to make sure our users still got the responsiveness they were used to and that they felt supported. We had to be thoughtful about how we scaled and migrated things when it came to scheduling and establishing a new communication path. You learn very quickly that over-communication doesn’t exist in situations like this. Everyone was so busy during this period with their day-to-day lives, stressing about Oracle “taking over,” wondering what benefits would look like, what our stock would look like, all of the aspects that get shaken up in an acquisition. They didn’t have time to worry about the IT stuff. My job was to lay out what was going to happen next week, warn them 17 more times about it, and tell them why they needed to do it. (When you work with technical folks, you can’t just say "do it," you need to tell them why.) Of course, there were hiccups and setbacks, but I felt it went as smoothly as it could. We followed the timeline, we pushed back when necessary, but at the end of the day we were always the biggest advocates for our customers, and that’s what truly matters.
Working across multiple teams and locations: the joys of Slack
One of my claims to fame is that I helped bring Slack to Oracle. Our use of chat ops and community was fundamental when integrating the team at Dyn with the Oracle Cloud Infrastructure (OCI) team. OCI was already really strong when it came to community building and was using HipChat at the time, but they were having some issues with it so we switched to Slack. It helped the two coasts talk to each other and work as a team instead of acting as separate entities. There were growing pains, but they were fixed by developing different channels and targeting specific audiences within the team. If we hadn’t done this in the beginning, I don’t know what would have happened down the road because the OCI team began to scale rapidly. The OCI team alone was 400 people, then when Dyn joined it was about 800 people, and by the time I left it was around 10,000 people—all in just four years. I don’t think we would have managed the same amount of collaboration and togetherness without a tool like Slack. The platform also makes it fun instead of forcing people to have only work-focused conversations. I was always the person to send “good morning” with a silly GIF. Even though it feels like you’re being a ridiculous cheerleader, most people do just want somebody to say hi to them in the morning.
Empowering others and being a manager
Something I always thought was a handicap of mine in the engineering sector was the fact that my knowledge isn’t rooted in the technical side of things. It felt like I needed to learn more technology once I was the manager to help support my team and speak to the projects when meeting with others. I was able to have enough trust in my people and learned to bring them along to the technical conversations. Ultimately, I will defer to them and let them speak for themselves rather than trying to translate what they said and mucking it up. If you trust people and give them the authority to speak in front of a room of people they might not have had the chance to speak to, not only does everybody understand things better, but they feel more empowered. I like to defer to the experts—they’re ultimately the ones who have to do the technical work. I don’t want to have to promise something that can’t be delivered because I misunderstood what was involved. I still strive to learn as much of the technology as I can, and I think I can talk the talk. Just don’t let me touch a terminal window.
I didn’t expect [that] being a manager and a project manager simultaneously can sometimes be in conflict. As a project manager, you don’t like it if somebody makes mistakes, but you have to trust managers to resolve those issues. Project managers need to influence without authority. You’re still driving people to get things done and be honest about due dates, whereas a manager is ultimately responsible if those dates are missed or their team doesn’t pull their weight. Managers have to deal with personality conflicts, performance reviews, all of that good stuff. So being asked to manage and be the project manager at the same time can create weird situations and conflicting goals. I often hire project managers that I can share my domain knowledge and context with so they can then run things on their own.
Luckily, HubSpot is such a kind and caring place that there hasn’t been a problem wearing both of these hats. There’s a lot of trust built into the system. I took my new role at HubSpot having not worked in IT in a while and I had a lot of self-doubt through the interview process. However, now that I’m here, it’s great and I’m able to do my job effectively.
It’s interesting that even after eight or nine years, I am still fighting my self-doubt about what I know and what I can do. At the end of the day, while I still feel like I’m lacking on the technical side of things, my grandest personal growth has been my blossoming confidence in myself and not letting impostor syndrome get in my way.
Ever since the pandemic started, my friends and I have been playing a web-based version of Dominion. We would get on a zoom every Friday and grab a drink, grab our iPads, and play Dominion for about 3-4 hours. It has been so much fun because Dominion is a card-based, deck-building game so there are infinite possibilities when it comes to playing through different situations. We have yet to get bored with it. Even now that we’re all vaccinated we still play on Zoom because it’s nice to not need to worry about driving somewhere or getting an Uber- we just jump in our PJs and hang out.