The CTO Journey: Mark Porter of MongoDB

When did you first fall in love with tech? And how did you get into tech as a career?

I first fell in love with tech when I was 11 years old. I started programming on a 4K Radio Shack computer and at 14 on an HP 64K calculator. The calculator program was pretty unique; Rich with oil revenues and also very cold, the Alaskan government was quite interested in people insulating their houses better and were willing to pay for it. With my program, you could walk around your house, enter all the info on your existing doors, windows, and walls. The program would calculate the maximum energy savings you could achieve through upgrades and would print out the paperwork you needed to apply for the grant as well as the information needed for a contractor to bid for the work.

This love of programming very quickly turned into a career as I taught and consulted all through my teenage years. My first major job was a contract with the US Dept of Education - I needed this to help pay for my tuition at Caltech. During my freshman and sophomore years, I wrote a course authoring and delivery system which taught Alaskan Natives in remote villages how to be paralegals or accountants. This allowed people with no access to higher education to get vocational training and make their way in modern society. It taught me that you actually can do social good and make money at the same time. It was written on an Apple II in Pascal.

Transitioning to a Manager Role

Some people in our community are thinking about making the transition from a developer to a tech lead / engineering manager / CTO. But many are unsure if they should really make the switch to a more managerial role. Do you have any tips on how to answer the “is this right for me” question?

This question of whether to go into management or stay more of an individual contributor is such an important one. I’ve written policies and documents on it. First, the company you work for has to make it clear that they will value you equally no matter which path you take. Many companies don’t do this, and some of the ones that do, don’t do it all the way. In particular, every management level should have an equivalent individual contributor leadership level and the pay should be equivalent. This opens the door for people early in their careers to make the right choice.

To make that choice, I advise people to watch themselves. See what they enjoyed every week and didn’t. An exercise I once saw somebody do is they went back in their calendar and colored all of their activities green, yellow, or red, depending on how much they enjoyed them, felt they added value, whatever. This exercise can help you realize where your heart and your passions lie. In general, the people who perform remarkably are the ones who have exceptional careers, including non-linear compensation compared to their peers. And most people only perform remarkably when they are doing something they love. That love makes the good things they do great and gives them the strength to weather the bad times without giving up.

If you find yourself attracted to trying to solve broad problems at the company, of technical architecture, go-to-market, product direction, etc, and you love working through people rather than doing everything yourself, than a management path may be for you. I read once “Management is the most noble of professions; in no other career can you help so many people so meaningfully”. I think this is true; but only for the people whose heart and passions are in it. If your passion is in technical excellence or your core job role, then try to excel at mastering that - assuming of course that your company gives you autonomy and a level career/compensation playing field to do so.

What was it that you had to learn, back then when you made the transition to a manager?

My wife and I have five wonderful children and something she told me when the kids were all single-digit ages has stuck with me to this day. One day my wife comes up to me and she says, “You’re losing our kids by being the same dad to all five. You think there is a “right way to be a dad”, but in reality, you have to realize all five need a different dad.”

I made that change and it had remarkable effects. It then took me a year or two to realize that the same mentality applies to being a manager and leader. Learning how to be a different type of leader, one who is the leader that each of your employees needs, not some recipe you have in your head, is something that takes a lot of investment, but definitely pays off.

I recommend figuring out what motivates your employees. What is it that brings that extra spark or provides that “a-ha” moment to them? With my kids, all have different interests and I allowed myself to come with them on their journeys. For example, my son is learning to be a pilot. Flying is not something I have a lot of knowledge about, but what people really want to be is validated. So even though I don’t know the first thing about flying a plane, I started learning more about it so I could understand what my son is learning about and be able to communicate with him more about his passion. Same for my daughter on sustainable development, my other sons on music and the military. I only have one child who’s a computer geek like me - the other four are all much more interesting, and I’ve grown through meeting them where they are.

What do you consider the most challenging aspects of your role today?

MongoDB is at a crazy intersection of time and the market. We have arguably better technology than most of our competitors, our software runs more places, and developers can develop on it. But very few people realize this. So the part that’s really hard is meeting people where they are with their understanding of the product; whether it’s them not understanding that our database has reliable ACID transactions like relational - all while being fully read-and-write distributed, or helping them understand our better way to program, I have to reset myself constantly. Every customer, every paper, every conference presentation is full of people who are at different stages of their MongoDB journey, and I have to be a chameleon to convey what our company does, who we are, and how we can help them.

Should a CTO Still Code?

Sometimes, there’s a debate about whether a CTO / Tech Lead should still actively develop code. What’s your take on this? Must or can a CTO still reserve some time to code?

This is such a great question. I’ll break it up into the CTO answer and the Tech Lead answer. There are many types of CTOs. A CTO at a small company who is leading the development of the company’s first product should absolutely code. A CTO who is focused on outbound activities for a major firm should not. For me, I still code, but I do it on projects with my kids and for myself.

As to Tech Leads, managers who are at the front line of teams that code, I believe that in the vast majority of cases, they should. They are at the juncture of using the tools, understanding the code, and having the management power to make the good things great and the bad things good. I strongly support leaders coding in the codebase up through at least first-line management and possibly even second-line management. Of course, with some teams, this isn’t necessary, but I’d be careful there.

On the other hand, of course, not every developer wants to transition into a management role! For those that want to keep developing software: is there any piece of advice you find yourself giving often to the developers on your team?

Yes, as we discussed above, developers should carefully consider whether they want to transition into a management role, and they should demand that their company authentically support both individual contributor and management career paths.

The piece of advice that I find myself giving is that going deep never gets old. Being the best person at the algorithms, or debugging, or your toolchain is so valuable to the org. Only the people who are the best can see the game-changing iterations or redesigns that need to be made - and have the confidence to make them.

I’m not a fan of people who leap from technology to technology (or company to company) every 2 years. At the end of 10-15 years, they are not the best at anything, but merely mediocre at a lot of things. And that’s about when in your career you should be thinking about getting promoted into the more senior engineering positions; but unfortunately, you’ve taken steps to make sure that you’re just not ready for that. I’ve seen many a career stumble at this point.

Non-technical Skills Required

Producing code is only one part of the craft of software development. What non-technical skills should a software engineer develop?

This is a topic I’ve written about a little bit as I regularly chat about this with my college-aged son and his friends who are CS majors. Developers’ jobs are unique in nature—they are not asked to produce a strategy, rather they’re expected to execute against strategy set by executives by producing digital experiences.

However, given how influential developers are to the success of today’s businesses they can elevate themselves to become more strategic thinkers and add new skills. One example of a valuable non-technical skill is improving your written communication. Being able to flex this muscle regularly will help you become an expert at communicating with both technical and non-technical audiences. Writing is clearly known to be the best way to think for yourself and the best way to communicate complicated topics to others.

Another skill that software engineers often lack is listening. After all, we grew up telling a very picky machine exactly what to do, and we didn’t really listen to any complex opinions coming back. It’s really important that engineers learn to listen to others, not interrupt them, and consider their thoughts carefully. This is another area where I’ve seen many software careers stall.

It would also be remiss to not mention how these skills are only part of the equation for success. It’s also helpful for business leaders to align their goals with development teams and provide the context necessary to execute the task at hand. I’m a big fan of Dan Pink’s “Autonomy, Mastery, and Purpose” push. Developers should regularly monitor how they feel about those three things in their roles and work to have all three be very positive.

It’s not a secret that developing software is a team sport. What traits, skills, and habits should an engineering team focus on to become a world class team - and not just a bunch of talented individuals?

These are three concepts I’ve used to build and scale teams successfully:

• Conway’s Law: Simply put, you ship your organization and communication style. For instance, if two leaders don’t like each other and they’re far apart in the organization then their two products aren’t going to work well together. Make sure your org and code and leaders are structured to represent the product you want to delight customers with.
• Dunbar’s Number: The idea of Dunbar’s number—that a human can only really maintain a certain number of social connections at once—is something that I consider when building and managing teams. You want to have teams and interactions which are within the Dunbar number, rather than building large, monolithic, 1,000 person teams where people don’t trust or know each other. In particular, if you share the most intimate thing a developer can share (an unprotected address space) with somebody they don’t trust, nothing good will come of it.
• Autonomy and Accountability: In my experience, you’ll find most teams want and crave autonomy and accountability. Whether you’re building software or not, the companies that work the best today have small empowered groups where they know what they’re doing, are allowed to make decisions about it, and have a connection to the customer. It is on leadership to guide and to help build an environment that provides freedom, candor, empowerment, and autonomy. With that, you’ll see your teams taking accountability faster than you could’ve ever forced it on them.

Additionally, these are the traits we value at MongoDB to create that sense of accountability and autonomy. These four all add up to more than the raw sum of their parts, because they all interact. For example, without psychological safety, people won’t risk being candid with each other.

1. Candor: To manifest a culture of candor, everything is low stakes. We want our employees to speak truths, about whatever the issue is, and deliver those thoughts with good intent and to receive feedback with good intent as well.
2. Context: We share a lot of corporate information and strategy (and even doubts and worries) with our employees because we believe our employees should have all the information needed for them to make their own decisions.
3. Empowerment: We don’t want to be an approval company. For example, as CTO I was asked to approve everybody’s travel and I rebelled against that - instead flipping the policy to me being CC’d and being given the option to question or disapprove if I wanted. Employees should be empowered to make their own decisions and it’s our responsibility to create the mechanisms necessary to accommodate that.
4. Safety: Everyone needs to feel psychologically safe in the workplace. No one plans to fail, but the reality is things do fail. As leaders, when we see experiments that didn’t work we need to embrace them and hold them up as examples of wonderful things that people tried.

Being the new kid on a team can be quite intimidating, especially in the face of large code bases and complex processes… How do you help a new developer in your team get up to speed quickly?

The “MongoDB Hierarchy of Needs” is a fun way to think about onboarding.

Our goal is for everyone to feel they are Belonging in two to three weeks. The goal of the first couple days is to get the administrivia out of the way: setting up the office environment, orientations about benefits, insurance, orientation training, etc. Every new person enjoys three layers of support: community support via our #new-hire Slack channel, their manager, and an “onboarding buddy”. Onboarding buddies are personal coaches and mentors that customize each new employee’s onboarding experience for maximum effectiveness. All this is supported by the company wiki, MongoDB University, and our vibrant online communities and affinity groups.

By about the second week, and usually sooner, most new hires have settled into their work group and begun learning the architecture, design, processes and practices relevant for the group. In this phase the entire team can be involved with helping the ramp up; this is almost always organized by an in-team mentor. Over the next couple months, we have suggested onboarding paths - each group has their own customized one - for people to learn about the parts of the company and their own team that are most relevant.

With time and experience, our new employees become the next generation of mentors, distinguished engineers, and managers.

Exciting New Technologies

Today’s tech world is brimming with new technologies. Is there any technology or recent development that you’re particularly excited about? Why?

Honestly, I’ve always been fascinated by databases. I think the promises they make in terms of durability, correctness, and availability are some of the hardest promises to make in computer science. So my answer is about databases, which might not be a surprise for somebody who is just as excited about them as I was 30+ years ago when I played with my first one.

What’s happening now is people are building platforms that run anywhere, that scale up and down as needed, and that are easier and easier to program against - even in this world of ever-expanding platforms, frameworks, and services. I came to MongoDB for a very passionate reason, and the technology I’m most excited about is what we can do for developers, companies, and customers over the next years, decades, whatever, with a single modern platform that lets you do OLTP, Mobile, Search, Analytics, all anywhere you want, at any scale you want. It’s one of the world’s hardest problems.

Separately, I am completely fascinated by the advances being made in chip architectures. Watching modern architectures like ARM take share away from the kludged and hacked legacy architectures is exciting. Data input and output speeds have gone up by orders of magnitude, and chips haven’t kept pace. I believe that with great cross-compilers, testing frameworks, and tools, we can keep engineers deploying on the most modern chip designs without any loss of productivity - and even really big gains.

About Mark Porter

Mark Porter is the Chief Technical Officer (CTO) of MongoDB, where he is responsible for crafting the long-term technology roadmap and vision for the company. Prior to MongoDB, Mark was CTO of Core Technology and Transport at Grab, Southeast Asia's super app that provides everyday services such as ride-hailing, food, package, grocery delivery, mobile payments and financial services to millions of people, from October 2018 to July 2020.

Previously, Mark was a General Manager at Amazon Web Services, from May 2013 to October 2018, where he led the Relational Database Service (RDS), Amazon Aurora and RDS for PostgreSQL, the AWS Database Migration Service, and the AWS Schema Conversion Tool.

Prior to Amazon, Mark held various roles including CTO of a division of NewsCorp and Vice President of Engineering at Oracle Corporation, as well as working at NASA/JPL and being an early member of the Oracle Database Kernel group. He has been professionally coding since he was 16 years old and founded and ran his own electronics services integration company.

Mark previously served on the Board of Directors of MongoDB from February 2020 to July 2020. He also served on the Board of Directors of Splyt, a global mobility company, and as a Board Advisor to MariaDB, a database company. He holds a BS in Engineering and Applied Science from Caltech.

You can follow Mark on Twitter, LinkedIn, and read his Blog.

MongoDB is hiring like crazy right now, MongoDB has doubled its employee size in the last 18 months. Mark is currently hiring engineers in places such as San Francisco, New York, Dublin, London, Barcelona, Sydney, Bengaluru as well as remotely.

For those developers new to MongoDB, they offer live introductory webinars weekly.

Additionally, if you’re looking to build new skills, check out their available courses via MongoDB University and the developer hub.

Looking for a Git client? Download our 30-day free trial and take it for a spin!

PS: Did you know? Tower Pro is now free for students as well as teachers and educational institutions!