Lessons Learned: My Journey from Intern to Manager
Four and a half years ago, I joined the QuarkWorks team as an intern. My goal was to get some professional experience on my resume for when I entered the industry full-time after college.
Nearly 5 years later, I am in a completely different position. I am one of two engineering managers in the company and a senior developer experienced in both native mobile and web technologies. For the last year and a half, I’ve had the pleasure to work as part of our business leadership team with our CEO, CTO, and my counterpart. I am in charge of recruiting and training new team members and in true startup fashion, I’ve gotten to be involved in pretty much everything and the kitchen sink other than that too.
We’ve never been too much about labels, but I think I can break down my time at QuarkWorks into 5 different stages. From intern to manager, I want to pick out a lesson I found important and share it with the world.
Stage 0 — Intern
Know when to ask questions and when not
There are 2 types of new developers: those who ask too many questions and those who don’t ask enough. And yes, there is such a thing as asking too many questions. Having been someone who’s done both, and also has trained a lot of people, I think I have an interesting perspective on this topic.
Reflecting on when I was getting started, I think that I did not ask enough questions. I’d say it’s usually against my instincts to ask for help on a problem or for information I don’t have (but I feel like I should know already). I think this is pretty common amongst many people, especially new developers. I see this all the time in people I’m trying to train. You want to prove yourself and show you belong, or you’re afraid of looking stupid or bothering your mentor too much. When I’m training people, this can be frustrating because I need to know when you’re stuck. It’s my responsibility to ensure you’re making progress. I don’t want to hold your hand, but I don’t want you to spin your wheels for an entire day either when I can probably solve your problem. Speak up! (or send a Slack message so I can get back to you when I’m ready 😉).
Then there’s the other side — folks who ask too many questions. I am absolutely guilty of this and still have to remind myself from time to time to work a little harder before distracting someone else from their own work. The problem is, when you learn who the people are who can get you an answer to most of your questions, it is easy to treat them like Google. Instant messaging tools like Slack have only perpetuated the “interrupt driven” workplace culture that is all too common today. I think this is a good time to mention one of my favorite blog posts, Maker’s Schedule, Manager’s Schedule. Hint: most programmers are makers. Even a slight interruption can throw off your train of thought and cost you 10–15 minutes of productivity.
There isn’t a silver bullet solution to knowing when to ask a question. At QuarkWorks, our rule of thumb is to spend 10–30 minutes looking at resources before messaging someone on Slack. That means Googling, looking at documentation, searching Slack history. If you’re still at a loss, that is a good time to talk with someone. However, your workplace might be different. It’s a good idea to ask what your boss’s and teammates’ expectations are so you can be most effective.
Stage 1 — Junior Developer
Trust your technical leads (don’t get overconfident)
Reflecting on one of my first big projects, I had the opportunity to work on a team with some great developers. We spent 9 months creating a social media app from scratch on Android to catch up to an existing iOS app. We had 4 developers on our team: 2 seniors and 2 juniors, and we moved fast. It is still one of my favorite experiences looking back.
At the outset of the project, while the senior devs were focusing on architecture, the other developer and I were charged with “scaffolding” the UI for the app. This meant doing a rough pass on building out the UI to get everything going and we would come back later to polish everything and “do it right” once we were close to the end. I tend to be a perfectionist, so not matching up the UI to the designs did not jive with me very well. I was also really excited to be working on something so cool. I ignored the orders I was given and spent a lot of time making everything perfect. In code reviews, I was often being told to just focus on basic functionality, but I kept pushing.
I did not understand it at the time, but the reasoning behind this approach was because of the long development timeline. The design and iOS teams were continuing to make strides on their ends and we were playing catch up. The designs we started with were not necessarily what we’d end up with, so perfecting things on the first pass was a big risk of wasting time.
Furthermore, I had gotten pretty sure of myself at this point and thought I knew what I was doing. In reality, I was still learning a lot about Android development and didn’t have a good understanding of how to make UI that looks good on all screen sizes and densities. So not only did I spend a lot of time “perfecting” the UI on the first pass, but the UI I did make wasn’t really that great at all because it would look great on one phone, but look like garbage on another.
I should have trusted our lead developers when they asked me to just focus on basic functionality. This was a painful lesson for me when I later had to go back through all the work I had done “perfectly” and replace it all.
I also witnessed this same thing recently with another developer. He was tasked with working on an architectural component on an app and was getting some feedback from another senior dev. He suggested doing it one way, but this person really wanted to do it his way. The senior dev warned him why not to do it, but the developer said, “no, no. It’s going to work,” and went ahead with his plan. It’s been a few weeks since implementation, and come to find out the exact problems the senior dev said would happen are happening. If this person had trusted the senior dev’s expertise, the project would be better off.
Stage 2 — Lead Developer
Invest in others more than yourself
A year and a half after joining QuarkWorks, I got the call to take on a team lead role. This was on one of our existing projects which had 3 other developers on the team starting out. Over the next year, the app would basically undergo a complete overhaul: a rethought design with new features plus a radically different backend architecture kept us busy with technical challenges year-round.
One of the more difficult things for me to learn was how to delegate work to others. Not the process itself of thinking something out and cutting it up into logical steps, but doing it in a way that kept the project on track with our partner’s expectations while also keeping people happy and productive.
This was a challenge for me because unlike before when I was one of the weaker links on the team, I was now the most experienced developer. There was a big divide between my skill level and knowledge of the codebase and my teammates’. I often got frustrated because I wasn’t able to lean on the other developers to execute on more technical tasks. When I tried, they would make a lot of mistakes or take 3–4 times longer than expected or both. It didn’t take me long to develop a “If you want it done right, do it yourself” mentality.
Furthermore, I really saw this as “my time to shine” as an architect in the codebase. I didn’t get too much room to work on architectural problems previously, but I always saw them as the “glory” tasks because the developers I looked up to were tackling them. I wanted to slay dragons.
As a result, I kept nearly all the more technical tasks to myself and divided up the remaining work to the others based on what I thought they’d like. It wasn’t perfect, but this actually worked fairly effectively. We kept up with expectations and delivered features mostly on time. I personally grew a ton as a programmer to the point where I was almost senior level by the end of it.
Fast-forwarding to a year later, it was time for me to move on from the project. QuarkWorks' client base was growing and we needed help kicking off new work. The thing is, when the time came, our team was in no way prepared to absorb losing me. I hadn’t invested a drop into helping others outside of code reviews and on-boarding a couple of new devs.
For several months, I had to invest a ton of time in training people to the point where I could be off the project for good. This was a really frustrating and painful period of time for me because I had to do this while spearheading another project. I needed to make a significant impact on both and it felt like I had two jobs. There were a few weeks during school where I worked 60 hours on top of my 15-hour course load.
The lesson I learned is as a technical lead, you need to be investing in those around you. And you need to do it from day one. Slay your dragons when you need to, but if you fight every dragon on your own, you’re not really serving the overall mission as well as you could be. This is especially true if you’re working in a growth-oriented company. Don’t perpetuate your problem by doing it all alone — put energy into your teammates!
Stage 3 — Senior Developer
Communication is maybe the most important skill you can have
Catching up to modern history now. Mid-2017 I was promoted to senior developer within our organization. At this point, I’d been working with Quark for about 3 years and gotten the opportunity to help create 5–6 different apps on Android and iOS. We had two other senior developers who had been with us a while. We worked closely with our CEO & CTO to define our company’s vision and strategize how to get there. Us senior developers focused on leading the engineering side of our company while our founders led the sales side of things. For us, this usually meant spearheading new projects, hiring and training new developers, and investing in our core team members.
As a senior developer, I’ve had the opportunity to be a technical lead on 5 different projects. I’ve also interviewed close to a hundred prospective developers, trained several others, and worked directly with many of our current clients. While I’ve certainly continued to learn on the technical end, most of my advancement has been in communication skills.
Some different types of communication I found to be critical as a senior developer are:
- Knowing who the decision makers are and how to talk to them
- Gathering requirements from both technical and non-technical people
- Training new and junior developers
- Knowing how to interview people as well as how to sell your vision
- Giving positive and negative feedback to teammates
- Working with other engineering teams within their codebases (politics!)
- Synchronization: daily stand-ups, posting in public slack channels, weekly reports for higher-ups, etc.
There’s a lot to unpack when it comes to communication and getting good at it. I think what it all comes down to is being a critical thinker and practice. There are two parts to any conversation: listening and sharing. These are two different skills. One is understanding what someone is trying to tell you, and the other is formulating in a clear way what you are trying to convey. “Putting yourself in the other persons’ shoes” mentally will really help with both of these. The best thing you can do is practice! Before any meeting or conversation, take time to consider who you are talking to, what you are trying to share, and why and how you need to share it.
The further I progress in my career, the more I learn that the people excelling are those who have strong communication skills. They know how to communicate their thoughts and also how to listen to others. Coding skill can take you a long way, but a huge part of making an impact in any organization is communication. Teamwork is the dreamwork ;)
Stage 4 — Engineering Manager
Stay organized
Something I love about QuarkWorks is how many hats I get to wear. Not literally. I almost never wear hats. But figuratively: I get to be a coder, a project manager, a boss, a recruiter, a marketing and sales person, and I even moonlight as a designer from time to time. Last year, after one of our senior developers left in January, I got the opportunity to start being more involved with management. It wasn’t something I was sure about, but it quickly became a big passion for me. There are four different facets to this part of my job: recruiting, training, relationships, and resource allocation.
Thinking about and spending time on all these things on top of my normal responsibilities has been a huge challenge. It’s also something that gets me up every day. When I got started, it was an absolute nightmare to make sure all this worked out plus my own things got done. I’d either be cutting corners, or one or two of my responsibilities would just fall through the cracks, or I’d be working all day…or all of three at once. How can I remember to email X person back when I have like 50 other things on my mind for the week, and 25 of them are more important?
These problems really compounded last year since we grew from 9 to 18 people over the year. Between us all, we were juggling 9 projects concurrently at one point! What I learned is the only way to stay on top of it all is to be highly organized, both personally and as a company.
How that should be manifested really depends on what works for you and your team. For recruiting, I like to keep a Trello board with every prospective candidate as their own card. The different lists are stages in the recruiting process. Any time something happens (I contact them by email, interview them, send them an offer, etc.), I comment on the card. I leave all my interview notes and thoughts on the card so when I forget the finer points the next week or want to do a retrospective or decide to send an offer, I can come back to it.
As for company organization, we’ve found that it’s really important to review responsibilities fairly often and make sure no one is overloaded. In a time where we’re really scaling up the size of our company, while also trying to maintain profitability, it’s imperative to organize in a way that’s as efficient as possible. You want people to be able to apply their focus on just a few things.
When you’re a startup, there’s no perfect system. Figuring out these problems is part of the attraction. Personally, I love facing the challenges and finding ways for our team to come out on top. It’s what drives me.
If you’re still reading, I hope you found something useful from what I think I’ve learned so far. There’s tons more I could share, but these are some of the most important things I’ve learned in my career to date. Knowing what I’ve learned in nearly 5 years so far, I’m really looking forward to what I can look back on in another 5 years. Cheers to all the people out there trying to progress!
