If Lou Montulli could pass along a maxim for the modern software engineer, it wouldn’t be from Steve Jobs or Elon Musk. He’d invoke a line from American poet Walt Whitman:
I am large, I contain multitudes.
In the decades since becoming a founding engineer at Netscape, Montulli has seen many founders grow into CEOs of companies and product managers become de facto CEOs of products. Yet with developers, he’s seen a drive toward specialization that sequesters them. In pushing forward a practice to build modularly, many have become contained themselves. Engineers should be known more for their expansive — not expensive — skill sets.
An engineer himself, Montulli came of age among developers who aspired to be polymaths. He did some of his most lasting and inventive work as an engineering jack-of-all-trades. Montulli developed two of the earliest web browsers, Lynx and Netscape, as well as browser innovations such as cookies and Fishcam, one of the earliest live cameras to broadcast online. His contributions lead to foundational elements of the web, including SSL, Javascript, and CSS — all of which he developed alongside the early engineering team at Netscape. He also held engineering leadership roles at Shopping.com and Shutterfly before becoming a serial founder.
In all these roles, he’s built and benefited from what he calls a creator-driven culture — the same environment that he’s currently seeding at his new company, JetInsight, an on-demand aircraft charter marketplace. In this exclusive interview, Montulli dissects a creator-driven culture and outlines the elements needed to cultivate it. At the heart of its success is a specific class of engineers: programmers who are driven — and have the latitude — to work outside their functional jurisdiction to build products. Any startup in its early days of building its engineering team will benefit from the advantages of this development culture.
Distribute The Problem, Not The Product.
If there is one linchpin to a creator-driven culture, it is the relentless practice of distributing a problem across more people, not just the product features that address that problem. It may seem like a subtle nuance, but the outcomes can be profoundly dissimilar. “It’s the difference between giving someone a jigsaw puzzle or a blank canvas. Even if both capture the same scene, the process and end results are distinctly different,” says Montulli. “In the first case, the parameters are set; the challenge is about execution and assembly. In the second, framing and addressing the task is as creative as the outcome itself. In this case, you’ve been moved closer to the problem, not just charged with assembling the solution.”
In the context of software, the parallel holds. “Creators need to avoid becoming just implementers, for the sake of the product and their own development. For example, it’s easy for engineers to slip into thinking their goal is improving ad impression efficiency a quarter percent every quarter, when it’s actually about delivering a better product experience,” says Montulli. “The way to avoid that regression is to create an engineering environment in which developers frame their work on a product-level, not a feature-level. But day-to-day deadlines and defined tasks can eventually bring them back into the weeds. So the key is to start them off with a part of the problem that the product addresses not a part of the solution that will solve it. A leader of a creator-driven culture will continuously remind her engineers of the problem and bring them back to it over and over.”
Without this active mindset, a typical engineering culture manifests, especially as a startup grows. Problem-level questions, which take an issue head on, eventually consolidate into fewer and fewer people. Most will cite scale, but it’s a tradeoff — conscious or unconscious — that’s to the detriment of the product. “What happens is that one person becomes responsible for making a product great, so only that person thinks deeply about the problem it addresses. Engineers are then assigned to help code for that person,” says Montulli. “Not only is that not fun, but not the most efficient way to build a product over the long haul. What’s more motivating and effective is to break up the problem that the product’s addressing into different areas of responsibility. By collectively attacking it on the level of its problem — not the feature — engineers are more empowered and engaged.”
The new PM in town
While the concept of a product manager is familiar, Montulli prefers to groom a different kind of PM: a problem manager. “It’s not a formal title, but the way I like to think of the type of engineers I want in my organization,” he says, “I base it off how I got started with Lynx. I began building it on my own, so not only owned the full product, but the complete problem. It became successful — more than I would’ve dreamed. I was forced to take every role: I answered all the emails, did all the packaging, builds, programming and product management. It became natural.”
Wearing every hat is typical for founders getting started, but the magic happens when this mindset is replicated — versus diluted — when others join in. “When we started Netscape, we were a small team trying to create an expansive product. It had a very creator-driven culture; product innovations really came out of engineering. We had a strong preference against being delivered features. We didn’t have anything against delegation — we each tackled different corners of a bigger problem — but more an aversion to an assembly-line mentality,” says Montulli. “Bring us problems! That’s all we asked, and in turn, we’d try to come up with really interesting solutions that solved not only that problem, but also a whole host of other problems that users hadn’t yet encountered or considered.
Optimize for byproducts. How likely will this work spin off something useful for another facet of the problem?
Montulli reinforces the practice of problem distribution with everyday tools. “When the engineers on my team go into JIRA, they’ll find a problem — not a feature — waiting for them,” he says, “Sometimes there’s a potential solution offered, but our default is to have the feature request articulated as a problem. For example, instead of giving a UI mockup image to an engineer and telling him to build a feature, we’ll post a problem. For example: ‘Users need to track expenses for pilots. They are currently using paper and physical receipts and need a better way.”
One problem JetInsight worked on in its early months was a way for operators to integrate with an existing industry database of hotels and rental cars around airports. “If we had taken the feature request at face value, we would have worked on a basic integration with the existing database. Instead we zoomed out to take in the bigger problem: information in the database was very quickly outdated. It was simple to use, but was so infrequently updated and only included resources close to airports, which limited inventory,” says Montulli. “By focusing on the underlying problem and having the technical understanding of the Google Maps API we were able to build a more functional integration using Google Maps, which gave us access to more resources, real time updates, reviews, photos and more. The experience is ten times better than what we would have gotten by using the existing database.”
In a creator-driven culture, problem-solvers become problems-solvers. Each action can induce many solutions.
When engineer becomes creator
The mindset of a problem manager leads to the type of developer who absorbs the practices of a traditional product manager. “Another way of thinking of this shift is that engineers absorb the purview of product management. Yes, these are challenging profiles to merge, and, yes, it requires engineers to take on different skill sets, but the effort pays dividends tenfold,” says Montulli. “First, when your engineers act as distributed PMs, it short-circuits the slow, painful and combative exchanges that often happens between PMs and developers. Otherwise, questions morph into extra meetings: ‘Are you sure you wanna do it this way?’ ‘Why do you want to to do it this way?’ ‘Let’s have a meeting and discuss it, OK?’”
The conflation of PM and engineering roles not only circumvents arduous communication processes, but more importantly gives the engineer an opportunity to address the problem at its source. “Some of the most original and impactful ideas I’ve helped build into reality — from cookies to the web browser — were ones in which I was exposed to a need early on and imagined what was possible from that point in time,” says Montulli. “So much is lost in the game of telephone between PM and engineer. Not only in terms of accuracy — some technical nuances may be lost — but also innovation. When the problem has been synthesized into a solution and broken into features on a roadmap, developers are not only two steps removed, but lose the sting of the customer’s pain point. That distance is a bad thing.”
To truly be a creator, the engineer must have skin in the game. “If an engineer is forced to develop and deepen customer empathy, you have a developer whose energy goes into figuring out how to build something customer-friendly rather than how to move onto the next feature,” says Montulli. “This shift changes the beneficiary of coding itself. Engineers aren’t handing off a feature to a product manager who gets it to the customer; they’re delivering it to the customer, one they feel connected to and don’t want to disappoint.”
In a creator-driven culture, makers bring their competency to the original challenge — not to the filtered version.
As engineers stretch across the value chain, their scope changes from features to problems to customers. “Products that engineers use in their own life tend to be better than ones they just develop for others. So, the more they can tap into the customer’s world, the better the product will fit into it. Customer visits serve to help engineers build empathy for users of a product they don’t use in their everyday life,” says Montulli. “Set a cadence for developers to monitor and engage with customers. The ideal is to get out of the office and meet them in-person. Send at least one engineer with Customer Success to meet your customers. We do that at JetInsight, at onboarding and about quarterly thereafter. In between visits, we schedule sessions with user recording tools, such as FullStory or Inspectlet, to see how customers navigate the product. This is in addition — not in lieu of — engineers joining customer visits.”
Here’s a bit more detail on how JetInsight goes about integrating engineers into customer visits:
- Onboarding. “Engineers rotate in to join a Customer Success person on an onboarding. They can participate, but they should be there to observe and absorb, like a scientist. Key areas to note are how the customer sees the product for the first time, how they work through sending their first outputs and the way they navigate the workflow.”
- Quarterly visits. “Even if it takes the whole day, an engineer needs to spend time with customers. In these check-ins, engineers should get to know the customer personally, take note of their dislikes as well as preferences and watch them use the product.”
- User Recording Tools. “Every week, we use FullStory to take in how our customers use the product. Engineers hear sales calls and demos, which can help with sales automation features and sheds light on the relationship between sales and other functions at a company. Ultimately, it’s more of a one-sided conversation, but it helps us pick up insights by osmosis and keeps us current between site visits.”
True creators need to have time with the customer, even if that takes away from a product development schedule.
Montulli recognizes that customer-facing interactions are not every engineer’s strong suit, but to craft a remarkable customer experience, it’s an eventual necessity. For those who are reluctant, he tries to ease them in alongside other engineers or employees. “If they're terrible at talking to customers, pair them up with another engineer in a visit. As a last resort, they can get that customer perspective by talking to their fellow colleagues and engineers after the fact. They don’t have to get everything first hand from the beginning, but that’s the goal.”
Increase Exposure, Not Communication
Creator-driven cultures seek to streamline product development by marrying elements of product management and engineering. Yet, there is still a need to sync before conquering problems independently. “As a leader, when you enable creators you give up centralized control. Management tends to be very flat in this model, which can be daunting if there are a few dozen problems at any one time that can — and need to be — tackled,” says Montulli. “We don’t want chaos, nor a pyramid model, so the way we go about it is to create relatively frictionless checkpoints that increase exposure of what’s in motion. That means that, built into their process, creators share what they are working on with key stakeholders, but that their colleagues also have the responsibility to actively opt-in to stay in line and informed.”
As an example, take one recent problem that a JetInsight engineer was tackling on compliance for pilots. “Here was one problem: The FAA restricts how much pilots can fly in a given time period and tracks their downtime between flights. There are complicated rules that every pilot must follow to stay in bounds. While pilots know and stay current on these rules, schedulers might not,” says Montulli. “Our challenge was to automate the tracking of those rules and tell a customer if they're going to violate any of the FAA regulations for pilot duty time. It turns out this is a big problem, as it requires extensive data input, from the specific minutes flown to flight training and other requirements that factor into these rules.”
The engineer tackling the problem came up with ideas, shared them internally in-person or via a screen share and collected feedback. The cycle happens quickly — often in a few hours — and later with customers by sharing early mockups. “Before investing time to build a prototype, fellow engineers and colleagues have seen the problem, framed by many possible solutions. They not only have the chance to comment, but are also exposed to how exactly the proposed solutions to that problem may impact their own,” says Montulli. “Over those hours, if there’s an idea that the creators like, the engineer works on a prototype. If not, it’s back to the drawing board. Either way, this process cinches the team together just enough that they can ideate with freedom, but also create in a synchronized way.”
In this specific instance, the engineer went back and forth with his fellow engineer on a lot of prototypes, but the winner became the next product feature. “In this exchange, another engineer realized that it wasn’t always clear which airplane from a fleet was actually being scheduled. So, not only did the engineer include the specs of the plane in his prototype, but as a team, we decided it was important to elevate that information into the top of the menu so it’s shown on every page,” says Montulli. “That’s the power of exposure. Communication is about sharing what you already know you want to say. Exposure surfaces observations and unknowns.”
Where exposure falls short, leadership steps in to pick up the slack. For small companies, this may be the technical co-founder and for mid-sized companies, this could be the VP of Engineering or Product. “To be clear, this is not a free-for-all where engineers can go after any problem they want. It’s the job of the engineering or product leader to monitor the mass of problems being tackled and continuously order and re-order the most pressing ones,” says Montulli. “The leader steps in to guide how the problems should stack and sync, ideally in a weekly all-hands and reinforced in 1:1s with team members. At JetInsight’s all-hands, I share all that I know about the market we’re going after, the customers we’re acquiring and the issues that those customers might face in the coming year. Only with that full context can creators feel confident that they’re choosing not only significant problems, but also relevant ones.”
A Caveat to and Catalyst for Creator-Driven Cultures
If this creator-driven culture seems most possible and stable in a startup environment, it’s because it is — but that doesn’t mean that it can’t be recreated in a larger company. “Just as democracy was in its purest form in city-states such as Athens or Sparta doesn’t mean it can’t exist elsewhere. It’s just more challenging. As a group grows, its members become more specialized, which means they operate on only a sliver of the problem. That’s why I’ve had the most success building creator-driven cultures within engineering teams of up to 20 people,” says Montulli. “After that mark, it becomes more difficult both from a management and execution standpoint, given the balance of latitude and coordination that has to be maintained. I’ve seen others break down problem sets in a way that allow 50-100 engineers to take independent action and still have some oversight. But there’s no doubt that coordination of releases gets challenging at that scale.”
The larger the company, the more critical it is for engineering leaders to pay attention to the seams between features and products. “It’s like going from a quartet to a full orchestra. It becomes more complex with so many elements in motion, which is why more attention needs to be paid to coordinating these distributive creative teams,” says Montulli. “Challenges usually arise with features that rely heavily on each other, leading to issues of scheduling and API interaction. Bigger engineering organizations are harder to sync because the outputs of these distributed creative teams must land around the same time. You'll never achieve perfection there, but you want to sequence them so they're more likely to deliver at a similar time.”
One tip is to group engineers by similar problems and product features as both scale. “By clustering similar sets of problems — and engineers who are tackling them — you can reduce their reliance on constant communication with their other co-creators. In this context, your goal is that they don’t need to talk to everyone, but can expose their ideas to everyone, if needed,” says Montulli. “Modularity in projects and problem sets really enhance the ability for people to work and innovate in independent way and increase efficiency. As Netscape grew, we had to modularize our teams to keep working efficiently. We split on product bounds, like web client and web server, and on the client side by operating system versions, such as Windows, Mac and Unix. It was a huge coordination challenge — and didn’t always work, but the times it did is when engineering teams had sight lines into the greater problem, even if they needed to collaborate with other engineering groups to implement the solution. In this case, modularity was better than monolithism — it was the lesser of two evils.”
What up-levels versatility is diversity
Beyond grooming engineers into creators, one surefire way to accelerate a creator-driven culture is to bring together diverse work backgrounds. Montulli saw this firsthand in his early days at Netscape, when the engineering team was determined to create better user experiences on the web. “We wanted to enable content creators to produce more dynamic content. Thinking back, it was supremely helpful to have engineers who came from graphic imaging and gaming in the room. When they looked at the problem, they couldn’t fathom an interaction between the user and computer that wasn’t naturally dynamic,” he says. “Even though computers in the early 90s weren’t fast, they assumed there was a world in which one could interact with a page and it'd change.”
Collectively, the group’s expertise — and instincts — led to new browser innovations, including Javascript, the DOM and interactive HTML. “Each engineer brought his own assumptions, expertise and perspectives. That allowed us to imagine and build new things,” says Montulli. “Granted, it was a very gifted group. We had different backgrounds, but we each made a choice to gravitate to products at the problem-level. That larger scope along with our collective technical acumen allowed us to see solutions that someone less technical, who may not have been super familiar with the data model underneath, might have missed.”
Tying it All Together
Creator-driven organizations build better products by distributing parts of a larger problem for engineers to tackle, not features for them to build to spec and implement. Key to the success of this culture is the functionally flexible engineer, who can stretch to take on traditional product management responsibilities and customer-facing interactions, all while having the skills to translate this firsthand intelligence into code. This culture rewards versatile engineers, who not only feel more empowered, but also stay more engaged with what — and for whom — they’re building. While this model’s suited for startups, with some coordination it can thrive as a company scales.
“To me, the best part of a creator-driven culture is it’s just a hell of a lot more fun to work on the root of a problem and not just be a cog in a machine. It’s why I like to build these types of environments. When makers can take true ownership and receive outstanding feedback from a customer they recognize, there’s little else that’s more satisfying. They connect to something more enduring than the product itself: the customer experience,” says Montulli. “‘I am large, I contain multitudes.’ Those six words were from Whitman’s major work, which he published with own money and kept revising until his death. He was not just determined to produce a masterpiece, but to connect to his fellow man through an American epic. That’s the drive you want to unleash in your engineers. You’ll be astonished what they’ll build as creators.”