Five Lessons for Managing Growth and Career Development in Software Companies
This blog post was adapted from the PGConf Silicon Valley 2022 session presented by Timescale’s VP of Engineering, Chad Berkley.
Managing growth and career development for software companies was the theme of my first face-to-face conference talk in two years. I have to admit it was nice to finally speak before humans following the pandemic hiatus.
I shared tips on growing a great software company that will scale with customers and the business. I did it through the lens of my career trajectory, drawing from experiences I’ve had in the last 25 years, working with some amazing people in equally amazing organizations. In this blog post, I will share some of these lessons.
But, to start off, I'll do a quick overview of my career so that you have context.
My Career in Three Acts
When I first envisioned this session on career development and managing growth, I was going to talk about my career in three acts, and then I realized that there is a prelude or act zero, which I couldn’t leave out. I’ll call it “Pizza and Gopher.”
Act 0: Pizza and Gopher
I lived in North Idaho, in the United States, in the 1980s and 1990s, which was a pretty depressed economy. My family didn't have a ton of money: if I wanted to do something or buy something, I had to figure out how to get the money myself. I started working in 7th grade as a pizza shop dishwasher and paper delivery person.
During this time, I had my first interaction with the Internet. In 7th grade, I went to the library to research a paper, and I saw a person sitting at a table with a computer. He asked me what I was looking for in the library that day. I told him, and he asked if I had heard of the Internet.
This was in 1991. Obviously, there was no Google, Netscape, AltaVista, not even AOL at the time. I noticed that this person was sitting there with what looked like a phone book. And it turned out that this was a book of indexed Gopher addresses. So, my first interaction with the Internet was with the Gopher protocol, a precursor of HTTP built at the University of Minnesota, which is why it's called Gopher. I spent about three hours with him going through numerous Gopher sites looking for information. I was hooked.
Act 1: Software Engineer
Fast forward to 1995, I graduated from high school and was looking to spend a lot more time with computers. I was introduced to coding by a friend, and I loved it—that's all I wanted to do. I loved making computers do what I wanted them to do. So I went to the University of Montana, majoring in Computer Science, but soon discovered that I wasn't doing that much actual coding during my coursework.
While I wanted to focus on writing software, my classes were set up for learning foundational concepts of software engineering. Basically, I was impatient, so I looked up jobs on campus that would allow me to write code. There were a lot of departments at the time looking for people to build databases and write software of all sorts.
Eventually, I had quite a few jobs around campus and ended up learning more in those jobs than in my coursework. I tend to learn better by doing anyway, so this part of my education suited me.
When I graduated from the University of Montana a few years later, my first job was at the University of California Santa Barbara. I took this job because I knew I would write a lot of code, and I ended up staying there for 11 years. But more on that later.
Act 2: Engineering manager
After working as a software engineer for more than a decade, I moved to engineering management. Like most of us, I’ve had my fair share of good and bad managers. At some point, I was having drinks with a colleague, and I was complaining about my manager, and I had this realization: “You think you can do a better job? Go try it!”
I started looking for opportunities to manage teams, and it turns out I learned a lot about people, careers, and how to build organizations.
Act 3: Org builder
Leadership is a loaded term that I prefer to use sparingly. Everybody in an organization has the chance to become a leader at some point, and I don't think that should be a term designated only for those at the top of the org chart.
But somewhere along the line, I became the chief technical officer (CTO) of FlightStats. It was around 2014, and I was only there for three years after starting as an iOS developer. Through twists of fate, I ended up managing the entire organization.
I moved into this role with its lofty title and had the realization: I had no idea what I was doing.
I entered this position with the hunch that I could do this job better than my predecessor, but I had zero experience managing more than seven people. Suddenly, I was managing 10 teams and over 75 people. But what I knew was that I had a great group of motivated people who enjoyed building great products for our customers.
By a chance encounter on a flight, I ended up meeting Salim Ismail. He’s the author of a book called Exponential Organizations. One quote from this book has stuck with me: "The only power we have as leaders are the conversations we start." And I would like to add the word “nurture” at the end of that: I don't think that leaders have to start all the conversations, but part of being a leader is starting or nurturing the conversations you think are important.
So, at FlightStats, I knew we had this great group of people, and it was really up to me to nurture those conversations. And you know, communication seems so simple, we talk so much about it. Not only do we talk, but we write, we transmit our intentions, aspirations, and frustrations in so many ways.
Good communication can be the difference between having a successful career or a broken one. It can make the difference between a 10 billion dollar valuation or a capitulation to market forces. One thing that's tied together all my experiences, from washing dishes to writing code to building organizations, is the conversations that I've started and nurtured throughout my career.
Some Lessons Learned
If you want something, be bold and ask for it
Back to my pizza roots, this is a photo of the place I worked in Sandpoint, Idaho. It's still there, and the woman who hired me still owns it.
I started washing dishes at this restaurant in 7th grade because I wanted a new bike. I walked around town trying to find a new job, and when you're 13 years old, you have no idea what you're getting yourself into. I walked around and saw the hours posted on the front of the restaurant: "Open 11 a.m. to 10 p.m." I thought: "Great! I'll go to work, be done at 10 p.m., go home, do my homework, go to bed, wake up, and go to school the next day."
Well, If you have ever worked in the foodservice industry, you know that when the last customers leave, the work really begins. And for dishwashers, it's often the worst. You’ve got cleaning, sorting, stocking—all sorts of things to do. Sometimes, I wouldn't leave until after midnight, and I would have to get up and go to school by 7 a.m. the following day.
This led to my first big lesson. I noticed that the cooks, waiters and hosts left a lot earlier than I did. So I went to my boss, the owner of the restaurant, and I told her I wanted to be a cook. Turns out one had just left and she couldn’t find another, so I started cooking pizzas. I was out of there by 10:30 p.m. and could get home to do my homework and go to bed at a better hour. Plus, cooking pizzas is way more fun than washing dishes.
So the first big lesson that I learned is that you need to make your intentions clear—if you want something, ask for it. Sometimes you're in the right place at the right time, and you can get what you want.
Lack of disagreement ≠ agreement
Remember when I told you I had worked at UC Santa Barbara for 11 years? This was in the early 2000s after I graduated from college. Eleven years at the same job in the software industry is a long time. In that time, many of you probably switched companies 3 or 4 times. I was there for the .com boom and the .com bust! But I enjoyed it, and I was growing as an engineer, or at least I thought I was. I moved through the ranks at UCSB. Engineer, Sr. I, Sr. II, etc. I was comfortable. I was complacent.
During high school and college, all I wanted to do was code. I actively searched for jobs where I could make that happen. I would move from one campus job to another to find fun new problems to solve. I learned how to work with different people, and I picked up new skills with each move.
When I got to UCSB, I let my career happen to me instead of actively nurturing the conversations that would lead me to improve my skills and move into more challenging and rewarding positions.
Around year nine, we hired a new engineer. They were a good engineer who quickly dove into the codebase and started asking very pointed questions about my design choices and coding. They pointed out that my Java skillset was at least two major versions behind the latest version of Java. They were polite but direct, in a way that my manager had never been with me.
My 29-year-old self was pretty upset about this. I was a senior engineer; I'd worked my way up; I was top of my class in college. How could this new person come in and say the work I had been doing was sub-par? I went to my manager and complained. His answer was: “Well, I have noticed some issues over the years.” My response was: "Why didn't you tell me?"
The confidence that I had used to succeed in the past had turned around to bite me. My overconfidence had intimidated my manager into not giving me the feedback I needed. It was on me as well because, honestly, I had never asked. I'd never started that conversation about my performance with myself or my manager. However, at some point, it was up to my manager to tell me I had lost my way and help me grow by having that tough conversation.
Just tell the truth
This experience led me to believe that I could do a better job and be a better manager.
When I finally got a chance to manage a team two years later, I vowed to tell people the truth no matter how hard. In my first week as a manager, I had to fire an engineer because the person hadn't written a working line of code in five months. The previous manager didn't want to deal with the conflict. I realized that my responsibility to the team, the company, and our customers required me to have that tough conversation.
The team realized that I was serious about building an environment where everybody could do their best work. We did everything collectively from then on: we talked about the goals of the product and debated the ways we could go about achieving them. We decided to track technical and business metrics to show the value of what we were accomplishing. We innovated tools and processes and gave each other tough feedback. We weren't afraid to say: “Hey, you dropped the ball here. Hey, you need to clean up your code. Hey, this isn't working right, so let's talk about that.”
It was truly a great team: we had a high-trust relationship, and people could just let each other know how they were doing. We also ate a lot of hot dogs.
We turned an unused cubicle into a hotdog stand, and it was a great way to build relationships not only within our team but with other teams as we walked around the office and offered hotdogs to other groups. It was yet another way to start conversations and help build trust amongst the teams.
During that period, my main lesson was just telling the truth. It became a significant theme as I moved to my next role as the CTO of FlightStats. I jumped into this role because, again, I thought I could do a better job. We could follow many paths, and the company was at that awkward startup stage where the many possibilities were obscuring a great idea, and people were fighting about which option we should choose.
I realized that nobody wanted to tell the truth about the company's state and that that responsibility had to fall on me. At one point, I went to the CEO and said: “We need help; we don't know what we're doing.” No one else wanted to admit that, but it would be the first small step to success.
Know when to ask for help
At the time, there was a very strong Agile community in Portland. I met a consultant through this community that I thought could help the company find its way. We ended up writing a check for $65,000 to this person, which was the largest amount of money I had ever spent on behalf of my employer. We started asking ourselves hard questions, and we involved the whole company in remaking it.
There were only two rules: nothing was sacred, and we told the truth to each other. We involved Sales, BizOps, HR, Engineering, and Product—every department—in deciding what we wanted this company to be. There were 75 of us at the time, and it isn’t easy to manage 75 people and get their ideas out, but we did it.
We spent a week rebuilding the entire company and changing the teaming model. FlightStats was eventually acquired, and we had a successful exit. The return on investment of that $65,000 check was well over 1,000x.
Five Lessons You Can Apply to Software Companies
So how do I use these personal experiences in building a great software organization here at Timescale? Here are my five takeaways on managing growth and career development in software companies:
- Don’t be afraid to ask for what you want
- Make it easy to see possibilities and try new things
- Foster an environment where people feel safe giving and receiving feedback
- Ensure people know it’s okay not to know
- Celebrate the act of asking for help and those that lend a hand
It’s all about the environment you create and the environment in which you work. We want to make it as easy as possible for people to see the available opportunities and for people to ask for what they want.
It seems elementary to say it, but when you’ve got people working on the things that they're most interested in, these are the things that they're probably going to be best at. It can take people a few tries to figure out which of those opportunities is the one for them, so you need to create an environment where they can explore, experiment, and try different things.
You also need to foster an environment where you can have difficult conversations in respectful ways. I'd say to managers out there that it's absolutely your job to have those tough conversations, and conversely, if you have a manager, it's your job to do the same with them. Having those bilateral conversations is incredibly important; it will only make your organization stronger.
The best organizations are those where people grow together, and I think that the best way to do that is by enabling healthy feedback loops and honest conversations about performance. Just tell the truth.
Additionally, creating a place where one can feel vulnerable is extremely important. Asking for help can be challenging, especially if you think you will be judged negatively for making a mistake.
When I had to tell the CEO of FlightStats that we needed help, I felt safe. I knew I wouldn't be fired or penalized because I admitted I didn't know how to solve this problem. That was a great place to be in, and I know there are a lot of places where you won't feel safe having these conversations, but it's vital if you're thinking about building organizations and building your career.
One thing that I'll finish off here is that asking for help is even more complex when it's seen as a sign of weakness, and one thing that we can do is celebrate people who are willing to ask for help and then obviously give them that help. If somebody is asking for help, support them by making sure they get it.
I put a lot of effort into honoring these lessons at Timescale, and I am open to learning new ones as I start and nurture those conversations that will keep us growing in the future. If you want to join the debate in a fully remote environment that supports work-life balance while building an exceptional product, check out our careers page—we have many engineering roles open!
