Leading Without Coding: A How-To Guide For Non-Technical CoFounders & Product Leaders

To those people who take on the bold challenge of creating a technical company without technical expertise on their founding team, I have written an article of guidance.

I hope that this piece is also helpful, by extension, to any non-technical people who work closely with engineers. And though it is not written toengineers, for those of you who decide to read this piece I hope it helps you get inside the heads of the smart, non-technical leaders and managers around you, so you can help them work effectively with you and other engineers to build wonderful things.

The background: In 2009, Brian Schechter and I decided to create an internet company (@howaboutwe). At that point, we didn’t know how to get the printer working, no less how to build and lead a world class tech organization. I learned on-the-job, largely through my work with the team of amazingly talented people we ultimately hired (after deciding that those freelance Belarusians weren’t the ideal solution). We grew HowAboutWe to about 100 people—and ultimately sold it to IAC. Hopefully, through this piece, I can help a few founders skip some of the ridiculous arduousness of my own learning curve (which continues to arc upwards to this day.)

KNOW THE STACK

Software is built through logic and is therefore eminently comprehensible. In almost all cases it works basically how you think it should and will work. To be an effective leader of engineers you must come to understand the peculiarities of the system: names, core principles, and workflows. I call this, “knowing the stack.”

Without knowing the stack, you will be basically useless. Worse—much worse—you will be an annoying drag.

But a fluent agility with this baseline framework (even if you can’t write a single line of code) will allow you — as a non-technical leader of engineers or simply as someone who works closely with engineers — to be relatively unimpeded in your efforts to bring deep value to the product development process through product vision, ideation, facilitation, planning, process management, recruitment and so on.

‘Learning to code’ is a noble pursuit that I support wholeheartedly, but I don’t think it’s necessarily more important for company- and product-leaders than learning to think and talk fluently about the code with people who can REALLY code.

To “learn the stack” I suggest three things:

1. Learn the Words — This means becoming fluent in the basic language and conceptual frameworks your engineers will be using in every technical conversation. You don’t have to understand the specifics of how complex algorithms are coded; but you do need to understand broadly how the software functions. (This way you won’t have to shame yourself by googling LAMP STACK and confusedly sorting through eBay results for vintage industrial floor lighting as I may once have done.)
2. Learn your way around GitHub
3. Learn basic SQL

For the non-technical founder (and adjacently for anyone else non-technical who works closely with engineers) it’s essential that you become fluent in the language and tools of the technical world. Learn voraciously. People love sharing what they know; so, just ask the right people the right questions, listen like an unabashed beginner, and don’t make the same mistake twice.

Once you know the stack reasonably well, you’ll be positioned to offer value to the product development process in ways more endemic to your non-technical nature. First on this list: facilitation.

BECOME AN EXPERT FACILITATOR

Most people have no idea how to effectively facilitate meetings, engineers included.

Take a random person (engineer or otherwise) and ask them to facilitate a complex technical conversation and you’ll likely end up in mire of opinions, ill-conceived next steps, discouraged quiet people, etc.

It follows that if you become unbelievably good at facilitating technical meetings you will be able to add huge value to the product development processes in your company.

Becoming the best technical facilitator in the room is a matter of skill and practice. It’s totally learnable. Here are the three keys: Translate — Structure—Lead.

Translate.

Rapidly translate the technical questions at hand into everyday English — or into whatever degree of technical language you can seamlessly traverse. This is a critical application of “knowing the stack.” You have to be able to facilitate each discussion in a language that every technical person understands and believes is accurate and sufficiently detailed — but of which you are also a master. This is eminently possible with many technical issues and major technical choices.

Part of this “translation” skill involves knowing when this translation isn’t possible—or isn’t worth the time—and rapidly relinquishing facilitation and decision making responsibility to someone with the necessary technical expertise. In these cases it’s often useful to remain a quiet participant, chiming in with non-technical information and opinions as needed.

Structure

Be hyper-disciplined about the structural aspects—the nuts and bolts—of great meetings. Here’s a rundown of what I think almost all good meetings include…

1. a) A clear purposestated as a concrete outcome you’ll have in hand as you leave the meeting (e.g. “an agreement about which javascript framework to use,” “clear next steps for deciding which javascript framework to use,” “a two-week roadmap to address app slowness,” etc.)
2. b) An agenda
3. c) Atime-limitthat won’t be broken
4. d) Breaksif the meeting will go more than 60 minutes
5. e) The right peoplepresent (obvious but often overlooked)
6. f) The right materials(shocking amounts of time are wasted each year by tech failures in meetings); this also includes making sure that there are visuals when appropriate and possible (could just be whiteboard notes), as many people listen and speak best when grounded with visual cues.
7. g) No phonesor devices unless they’re needed to achieve the purpose of the meeting.
8. h) A facilitator/meeting leaderin charge of clarifying the purpose of the meeting, sharing and sticking to the agenda, ensuring the purpose is reached, ensuring adherence to decision making processes (even if this is not explicit), making sure that the right people get the chance to participate, summarizing the meeting’s progress at key junctures and at its conclusion, ensuring that documentation occurs as appropriate, and keeping track of and disseminating action points.
9. i) Agreement (subtle or stated) about how decisionswill be made. It’s 100% fine if the answer is: “I am going to decide” — but this needs to be clear to everyone. When decision making processes are wishy washy, people stop focusing on how they can contribute their perspective and expertise and instead start focusing on winning; this is distorting, conflict-creating, and wasteful.
10. j) Smart processesfor ensuring that all important points are discovered and heard. “Important” here is being defined as helpful for achieving the meeting’s purpose. This is the least concrete point on here, but it’s key and requires thoughtfulness to achieve. Brainstorming can be an exercise in banal obviousness or a genuinely creative wellspring. Sprint-planning meetings can be dreadfully boring or rather fun. Big technical debates can be contentious or light and enthusiasm-generating. The differences here are often dependent on the meeting modality or process. Grow your toolkit and choose wisely.
11. k) In some cases, (subtle or stated) groundrulesfor how people are going to participate. This could include things like: “rationality over sentimentality;” “no interrupting;” “everyone speaks once before anyone speaks twice;” etc. I say “in some cases” because this point is very dependent on a company’s culture. In all companies some set of groundrules are implicit—that’s what a culture is. Whether you decide to make them explicit is, well, a cultural decision.
12. l) A synthesizing conclusionthat reflects back on the meeting’s purpose and ensures the next steps are crystal clear and owned by specific people.
13. m) Acknowledgementfor people’s participation
14. n) Ease. As opposed to what this list of meeting necessities might make you think, great meetings tend to feel relaxed, natural and fluid.

Lead

This is an umbrella for the subtle aspects of facilitation—the hundred tiny things you do and don’t do to maximize efficiency, morale, creativity, and so on in every meeting.

This includes things like: reading each person in the group to understand who needs what to contribute their best, feeling out what rabbit holes are worth living in and which should be escaped immediately, managing interpersonal dynamics without doing so head-on, building enthusiasmahead of challenging moments so the group has the energy to work through them, conveying deep process integrity, allowing for silence, defusing bifurcating ideological battles, using humor to maintain levity at the right times, and on and on.

These are the “leadership moves” that differentiate decent facilitators from masters.

Above all, leading in a meeting means being present and really understanding the goal and what needs to happen to achieve it. This absolutely does not mean: “be heavy handed.” The best facilitators are often nearly invisible. You in no way need to be at the center. You just need to make sure everyone has what they need to do their very best, collaborative work. You are facilitating this excellence and motivation.

Sometimes, your perspective is essential to the meeting (particularly if you are a co-founder). In such cases, you may find yourself acting as both facilitator and actor. This can be really confusing for people, and it can seem like you are highjacking your own meeting. For this, I suggest making very explicit (inside and out) when you are facilitating and when you are participating. If you as participant are highjacking things, you as facilitator needs to realize this and tell yourself (probably inside only) to shut up.

One last note on meeting facilitation: as long as your technical limitations don’t become roadblocks, you are actually the ideal person to have as facilitator. By moving the conversation into a space of, let’s say, “accurate technical metaphor “ — the linguistic terrain of someone who knows the stack — you’ll end up focusing on the essence of the debate or question at hand. Further, you’ll bring a broader product- and company-perspective to the conversation. What’s the actual resource cost to the “ideal” solution? How does this topic play into and align with our long-term product vision? How do we ensure that the user is that the center of this decision? How will we know if this succeeded? And so on. Be confident that you—as a non-technical facilitator of technical meetings—are bringing (even if you don’t explicitly raise them) important, overarching product- and company-focused perspectives to the conversations you’re facilitating.

RUN THE SMARTEST SHIP

If you think the average Joe sucks at facilitating meetings, you should see him run product/engineering processes.

The most important trick you, as non-technical co-founder or non-technical product leader, have up your sleeve is to build a seamless, highly-efficient product development process.

Here’s the thing: strikingly few engineering shops are really well run. Some are awesome, of course, but the vast majority are at least half-broken. Engineers are constantly getting blocked, wasting time on duplicative or misguided tasks, lacking the data to make strong independent decisions, missing structures for design collaboration, unable to effectively deploy, interrupted in ways that inhibit creativity, mired in useless refactoring projects, etc. And the rub? Most engineers live with this tremendous inefficiency, shrug it off as a sort of natural state of things, and just do their best.

When you build a top-notch product development processes, the engineers (and designers and data scientists and marketers and salespeople and everyone else) you work with will be happy; and a happy team is a beacon of glory and productivity.

Ok, so how do you do this? Monstrous topic. A while back I wrote a ridiculously long, seven-part piece outlining the theory and practice of product development, down to the details of specific meetings and sprint workflows. In this piece, I’m going to try to narrow this topic down to twelve principles to which I think most great shops adhere and most garbage shops don’t.

Sequester Time for Creativity

The center of product development is creativity, which is why this one goes first. And being creative requires time and space that often feels rather pointless. This time and space, therefore, are usually the first to be eaten in the inevitable “meeting creep.” Don’t fall into this trap. Creative time—for everyone on your product team—needs to be sacred, untouchable, and uninterrupted. If you fail at this but succeed at everything else in this list you’ll very effectively build uninspired, shitty things.

Sequence to Avoid Blockages

Developers should never be without everything they need to build whatever they’re building. Data architecture work should be done before application layer development. Design shouldn’t start on a project without a sense of unbreachable technical limitations. Front-end devs should have PSDs in hand before they start coding. And so on. Point being: each aspect of the product development process needs to be intelligently sequenced. Turns out, this is hard as hell; get it right.

Predict and Eliminate Unnecessary Bottlenecks

There are always bottlenecks. And so you should always know where they are and where they will be next week, next month, and next quarter. Your goal should be a situation in which all bottlenecks are caused by unavoidable resource constraints. For example: it’s very different if one of your development teams is blocked because your designers are working on higher priority projects and there isn’t the budget to hire additional design resources than if the devs are blocked because your designers have been wasting time on something inessential. The former is the best you can do, the latter is bad management.

Optimize Decision Making Processes

And by “optimize” I almost always mean, “minimize.” Law of nature: the more decision-making cooks, the more suffering. Get super clear about how decisions are made and by whom. Flag of efficiency in hand, fight the tendency of groups to stray towards democracy. It’s often better, particularly in early stage companies, to go four times as fast and make 25% more errors.

Invest in Seamless Systems for Development<>Testing<>Deployment

A shocking amount of time can quietly disappear into the morass of environment set-up, branching, merging, rebasing, running tests, deploying, pull request flows, rolling back, and so on. And not only time; also, morale. Making the workflow for engineers seamless can be a huge win. Though, I will add “do this at the right time” because over- or premature optimization of such workflows can itself be an even bigger blackhole.

Systematize Ideation, Road-mapping, Sprint Planning, and Daily Coordination

These four aspects of planning should become systematized in ways that align with your company’s culture. If your culture is decentralized and modular, so should be your processes for coming up with ideas, prioritizing them in medium- to long-term plans, organizing small-ish chunks of team-based work, and then managing this plan on a daily basis. Likewise, if your culture is regimented, top-down, etc…so should be these planning systems. The point here is that they should be systems: thoughtfully designed, repeatable processes to which people understand how to contribute.

Run Design, Development, and Data Science/Analysis as One Process

There are many important differences between how engineers, designers, and data scientists work. None of these differences justify the tremendous costs of having three radically distinct workflows for these areas. By streamlining processes (obviously allowing for minor differences relative to the nature of the tasks at hand), you create a ton of efficiencies, collaborative strength, etc. Unforunately most tools (e.g. Pivotal Tracker, GitHub, Jira, etc.) aren’t designed with these three groups in mind; however, they can and should be hacked to accommodate this larger efficiency-oriented goal of unity.

Make Asynchronous what should be Asynchronous and Synchronous what should be Synchronous

Basically, anything that can be done through Slack/Email/Github/Tracker/etc without a synchronous conversation/meeting should be done in that manner. Each additional person involved in a synchronous conversation makes that conversation incrementally and probably exponentially more time consuming than an asych version of the same dialogue. Except when the conversation actually needs to be a conversation—in which case the reverse is true (see: endless email threads in dire need of a facilitator). Become a wizard at systematizing this synch/asynch designation.

Be Urgent. Be Realistic

Work should be filled with a felt sense of urgency, but also with a realism that protects you from constantly missed deadlines, false promises and resultant inefficient scrambling, burnout, etc. Nailing this balance is primarily a matter of effective planning and goal-setting.

Ensure that the Right People are Working on the Right Things

Sometimes an engineer is best off working on something that is way over his head; sometimes he is best working on something that is menial and horribly annoying. Determining the “right things for the right people” is extremely circumstantial and thus hard to systematically define. But without careful planning and thought, it is unlikely that people will naturally end up working on the “right thing.” The problem is that such careful planning and thought often reeks of micromanagement, lack of trust, judgment, etc. Or, even more simply, it just involves asking people to do things that aren’t pleasant. Build a culture of smart, conscious decision-making about who is doing what.

Prioritize Maniacally

What you prioritize is what you value as a company. So, the prioritization process is the process through which you determine and express the company’s values. Said otherwise, how you prioritize is how you place your bets. Become maniacal about this process, ensuring that you don’t do anything that isn’t the next most important thing that can be done. Some teams believe in highly decentralized prioritization (e.g. whatever you want to work on next, do it); when this works it’s either because people in the company have an incredibly deep understanding of what matters or because the structure of decentralization itself is the critical thing that needs to be constantly expressed and solidified. The clearest sign that smart prioritization isn’t happening is stupid perfectionism; if you see that happening, you know you need an upgrade to “more maniacal.”

Treat your Process like a Product.

Whatever processes you create, they won’t be perfect now and they certainly won’t be perfect in six months. So, treat them like a product: test them, iterate on them, kill the bad ones, etc. Proactively create consistent space and time for reflection, and build iteration into the process; this way people will always stay constructive. The problems you encounter will all feel like opportunities to improve rather than errors. And you will constantly improve.

You do not need to be technical to follow these principles. But you do need to be disciplined and strong. Do it.

Become the bastion of technical process integrity in your organization; aside from hiring amazing people, this the most important thing you as non-technical leader can do to ensure that you build great things.

Master The Data

Mastering the data is, in some regards, just a subset of “Running the Smartest Ship”; however, it’s such a powerful leverage point, that I pulled it out as its own section.

To orient all of your choices towards maximum learning and thus maximum improvement inside a given time horizon, you need to be completely relentless early on about establishing smart processes through which you collect, analyze, and act on your data. This work, often fairly arduous and downright annoying, will pay crazy dividends over time. It will create a guiding force for your engineers and product organization at large. Here’s the 101:

Get Canonical

Build a central location — ideally in your code but easily accessed, understood, and updated by any analysts — where all your key data definitions live. What is a user? A conversion? A paying user? A channel? A source? The steps in your sign-up funnel? These definitions will inevitably evolve over time, but they should be crystal clear and shared across your organization at any moment in time. Your engineering team should be fully involved in establishing these definitions, both because they will be best equipped to do so from a data engineering perspective and because doing so will help create seamless integration between engineering and the company at large.

Decide What Matters & Monitor Growth Maniacally

Which metrics are most important for your business? These should be the metrics that give you the clearest and most penetrating view into whether people love and are discovering what you’re making in a cost-efficient way. Let’s call these KPIs (key performance indicators). You can have company wide KPIs (maybe ~4) and sub-KPIs for each of your teams (maybe ~4). Track these transparently, and monitor growth/improvement maniacally (ideally on a weekly basis). This is your inner scorecard. It will align everyone around a common purpose and measure of truth.

Build a Dynamic, Predictive ROI Model

Construct an ROI (Return on Investment) model early on that’s flexible enough to adapt to your evolving understanding and to changes in your business. This means having, on the one hand, a predictive LTV (Lifetime Value) model. Ideally this model is based on users (not paying users), and has the capacity to include variations on LTV based on segmentations like channel/source, demographics, etc. Because it’s predictive (even if your algorithms are very rudimentary), your engineers should be heavily involved. On the other hand, build a CAC (Customer Acquisition Cost) model that bundles any and all costs (including but not limited to marketing spend) that you can relate on a per-unit basis to the acquisition of your users. It should include an understanding of COGS (Cost of Goods Sold). The result should be a dynamic model that gives you a reliable, relatively real-time sense of the health of your business. Ideally, this model also allows you to measure changes in your product or marketing/sales tactics relative to their impact on ROI.

Find your Tools and Commit

Commit early to a minimum number of centralized and thoughtfully chosen or homegrown platforms for data reporting and analysis. There are a plethora of options, and unfortunately there is no great universal solution. Still, try to keep the number of tools to a minimum and avoid a situation in which the company relies primarily on ad hoc SQL queries, CSV dumps, Excel/Drive spreadsheets and graphs with no version control and limited reliability. (Way harder to avoid than you might think!) Every tool will have downsides, but there will be disproportionately more upside in committing to and mastering these tools across your company. I think it’s safe to imagine that ~20% of your analytics work will be ad hoc because of tool limitations, complexity, etc.—but if you feel that 20% creeping up to 30 or 40, don’t hesitate: assess whether you need to add a new tool, better train your team, or just tell everyone to stick to the program.

Frame Everything as an Experiment

Instill and inspire in your engineering team (and everyone else in your company) the ethos of constant experimentalism. This mindset implies that, to whatever extent possible, every feature should be launched as a test. Build (or choose) a framework for smart multivariate testing. Be sure you get the fundamental methodology (statistical significance, collision awareness, etc) right from the get go. And then treat everything you do as an experiment. This will align your engineers and company as a whole around a data-driven orientation towards constant growth and improvement. Plus, it makes things more fun.

Cultivate a Culture of Intelligence

Obviously. But, in practice, intelligence is a difficult attainment. Let’s say you are in a situation in which you are comparing Option A v. Option B. Option A seems like it won by 25%. However, there is a 10% chance Option B actually won. But if it did, it won big — by 50%! It will take an extra two weeks to get more clarity about the outcome. (Not a real situation—and possibly statistically impossible—but it highlights the quandary.) Your inner data analyst is saying you need to wait for more clarity. Your inner business aggressor is saying, choose A, eat the potential loss for the risk adjusted 20% win and to save the two weeks of opportunity cost, and move on. What do you do? Maybe choose A and spend a day building anomaly testing so you can detect if A is actually a real loser? Merging creative solutions with cutthroat data analysis is the blurry space of optimal action and intelligence; it’s this attitude and dialogue you want to cultivate in your company.

Know the Limitations of Data

No one ever created something magical through data analysis. If small-minded hyper-focus on data granularities is limiting your intuition and creativity, you have a problem. Put data in its place. It’s a prince, but it ain’t the King.

Mastering the data means mastering your company. Help your engineering team become the company’s strongest heralds—and indeed the protectorate—of the data…its storage, accessibility, definition, analysis, etc. This will align them with the business as a whole and empower them to empower everyone in the organization to do great work.

All of this however, is moot, without amazing people…

HIRE GREAT PEOPLE & REPLACE YOURSELF

Hiring great engineers is painstaking, but doable—and critical. Find them. Assess them. Close them.

To find them, hunt. If you think at some point in this process, “This seems like an endless search in which 99% of my work is utterly futile,” you’re probably on the right track. It’s essentially a networking and sales process; all smart swagger and hustle.

And once you know that an engineer you’ve found is the real deal, you should be able to close them. Be deeply honest. Compel them through your humanity and vision. Use cash and equity intelligently. Never forget, even when you’re selling hard, that your attitude should be that of the buyer.

For the non-technical leader, assessment is often the trickiest part, particularly at the beginning. The stakes are high here because if you make an error you will really regret it.

You’ll definitely need some support to know who’s technically strong and who’s not. You should hire a consultant to help you with this if you don’t already have a strong team in place to play this technical screening role. This aside, I’d say that at least 70% of what makes a strong engineering hire can be assessed by you.

Here’s a list of eight non-technical qualities you should look for:

• Pragmatist (They feel that not taking the most efficient route from A to B is like eating glass.)
• Doer (They have created things in their lives, enjoy getting stuff done, know how to take something from start to finish amidst various obstacles, and are happy to work diligently on a hard problem over long periods of time.)
• Independent thinker (Important, not for the sake of being a doubter but for the sake of finding the best solution.)
• Collaborator (No drama queens. No arrogant assholes. Not too cool. Not too too weird. Fits your culture)
• Communicator (Great communication skills are an often overlooked skill in engineers but is very important, particularly in early-stage, collaborative product building.)
• Maker (They possess a deep desire to build things that people use and adore. They love the internet. And they are excited about your particular product and vision.)
• Expert (They bring deep expertise about something of value to your company. Ideally they are also already well versed in and aligned with the methodological and philosophical particularities of your technical environment — language, testing, tooling/environments, etc.)
• Enthusiast/Evangelist (Working for your company will be an awesome move for the person. If it’s not, it won’t work out. Everyone at your company should feel that what they are doing is great for them. That way, as long as they’re strong, it’ll be great for the company. This kind of symbiosis is what makes for truly great, cohesive teams.)

Be relentless in your choosing. Deeply probe references; everyone has weak areas, so if you’re not hearing about these in your reference calls know that you’re not asking the right questions. Don’t settle, particularly on issues of character. It’s not worth it. You’ll pay for it later. A bad engineer costs ten times more than a missing one. And, at least early on, a great engineer is genuinely 5x more valuable than an okay one.

For the non-technical co-founder who is leading the engineering team, your most pressing hiring challenge is to find a technical leader and hire yourself out of this aspect of your job.

Because honestly, not to burst your bubble, but even if you absolutely nail everything I’ve outlined in this piece, you’re still not the one to lead a serious engineering team. You will come to know your stack, become a wonderfully adept facilitator, build seamless processes, master the data and hire an inspired team…but even so, you need true technical leadership.

The sooner you replace yourself, the better.

Ready Yourself, Inside

If you are starting a technical company without a technical co-founder, you may be a bit of a crazy person, more enticed by a challenge unrealized than by known alleyways.

Not to homogenize, but you have very likely spent much of your life so far winning. Now it is time for you to experience a whole series of things that most people confident and gutsy enough to be non-technical founders of technical companies haven’t experienced too much: deep confusion, a perpetual feeling of quasi-helplessness, and so on.

So, to make your way, you simply must cultivate an attitude that can sustain you through the inevitable impending challenges.

This might mean embracing an abiding sense of humor (my spiritual weapon of choice); a relentless inner stance of ‘ends justify the means’; a sense of self-acceptance regarding what you know and don’t know; a scientist-like attitude of experimentation and joy in learning; a sweetly melancholic appreciation for your own limitations as a person; an American Salesman-like grandiosity that you can carry as a banner through any storm; a teeth-bared rugby-style competitive crouch, or perhaps a quiet and inspired awe at the esoteric knowledge of the craftsmen you will employ and at the grand mechanism of Capitalism itself. Whatever works.

Find your inner cocktail of strength and uplift. Suffuse yourself in it. The road to victory for the non-technical founder in charge of product and engineering will inevitably be traversed on many days with ragged knees and furrowed brow. You must find the stance that will sustain you as you learn to guide your team to build best-in-class products.

You will learn. You have to. Be patient; if you want to make products that millions and millions of people use and adore — products that make humans smarter and brighter — you need to put in your years. Luckily, human qualities like perseverance, commitment to growth, ambition, skill in communication, and openness are ultimately far more powerful than any particular capacity or craft. So, hunker down, stay calm, trust your mind, and keep the faith. Be prideless and full of a deep belief in other people. Remember to laugh—hard—at yourself.

Making amazing things is a hard-wrought attainment. Go for it.