This is a collection of my thoughts on helping to enable effective software and digital product teams. Some of it is backed by research, some is from conversations with a myriad of wonderful people I very much respect, some is from experience. If you’ve landed here in some way this is probably a subject that matters to you. Software Engineering plays a role in almost every modern corporation. This is demonstrated in the fact that there are 4.4 million software engineers in the United States. That’s about 1 in every 30 working people in the country. I’m specifically writing this for those working in Software Engineering at companies that are “Software Enabled Companies”. What do I mean by this?

What is a “Software Company”

I often here engineers flippantly throw around the quote that all modern companies are Software Companies. All modern companies are software enabled companies, but all modern companies are not software companies and the distinction is important.

Software Company

1. The product you sell is your software
2. Selling more product has a theoretically 100% gross margin
3. Your product scales infinitely enabling easy effective monopolies

Software Enabled Company

1. Literally every other company. (Aside from mom + pop companies that don’t yet need any software)

Let’s examine this for a second.

Google

Google is a company that produces alot of software. Are they a software company? Yes. Why? The product they sell is software that distributes of ads. To distribute another ad, someone else makes the ad, puts it on their platform and then the theoretical incremental cost to distribute the ad is 0, making the theoretical gross margin 100%. To scale their revenue, they don’t need to do anything. They could all sleep in, not go to work, and the product would scale by virtue of customers signing up and creating more ads.

Tesla

Tesla is another company that produces alot of software. Are they a software company? No. What!? They produce the software that powers their cars, right? Right. But someone else could also produce the software that powers their cars and it would take nothing away from Tesla, in fact it might even lower their costs. They make money by selling cars, not software. Each car they sell has a defined margin and they can only scale by building larger factories. If they all went home and slept their car manufacturing capacity would at best stay the same.

Why is the distinction important?

Building good software at a “Software Enabled Company” is a much harder problem than building good software at a Software Company. The near 100% margin at the Software company is able to paper over many mistakes and enables behaviors that would never make sense at a Software Enabled Company simply because it doesn’t make sense to allocate as much of the companies gross revenue to software.

1. Companies like Microsoft and Amazon can afford dead projects. Dead projects that eat 5% of their gross revenue also eat 5% of their hypothetical margin. Mistakes to be sure, but not life and death mistakes. At a company that say makes products and has a 30% gross margin, a project that eats 5% of their gross revenue would erase over 15% of their gross margin, which might make the difference between making and losing money.
2. Software Companies can experiment with technology. Something like React Native could only have happened at a software company which means that Software Companies are not constrained by existing toolsets.
3. Software Companies have much easier access to talent. They can afford to spend more time doing things like blogging which improves their external perception and makes hiring significantly easier.
4. Software Companies don’t have to worry about obsolescence of their software. Airbnb will not ever be deprecated by Airbnb, it’s the product they sell. If however you are Tesla and you make auto-pilot software, there is probably a company out there looking to make auto-pilot software and sell it to all the car companies. Their economics makes much more sense than yours, they can build once, sell thirty times making the cost of the software on a per customer basis 1/30 Tesla’s cost. Tesla’s auto-pilot engineers should not count on the auto-pilot software product continuing to exist forever.

All of these factors conspire to make building software at Software Enabled Companies require significantly more rigor and discipline than building software at a Software Company. Add to this the fact that the internet is littered with resources from companies like Airbnb advocating a set of behaviors that works for Software Companies. It can be hard to decide on the right tactics and strategies to manage your team and drive your company’s success. For anyone in this situation I hope you find this a useful resource.

Effective software teams enable effective companies. There is no scaled company on the planet that doesn’t employ some degree of software engineering, whether it’s interacting with consumers, understanding data or enabling behaviors.

1. Software teams can create competitive advantage. Any behavior your organization wants to deliver at scale requires software. For example, if you’re advertising at scale on the internet you are likely using facebook business manage and google ads. What if you want your organization to do something at scale a competitor can not do? You definitionally need to write software. If you are able to buy software that enables this behavior, you competitor can too and your organization is not doing anything at scale your competitor can’t.

   EG The Honest Company was started in 2011 and at the time subscription commerce wasn’t something you could buy off the shelf on the internet. Honest build custom subscription commerce software and was able to rapidly dominate a market that lent itself particularly well to replenished orders, diapers. Being the only player in the space with an auto-replenishment feature gave the company a significant competitive advantage over similar companies.

2. Software is very expensive. A minimal team of 3 engineers, a product designer and a product manager will cost $550,000 per year. Once you have software running a team that size can spend all it’s time maintaining that software, which will not add any additional business value. YouBy committing to hiring a team and paying them to build a piece of software you’ve committed to a $550,000 yearly software subscription.

3. Software is additive. Good software makes it easier to change. Bad software is harder to change. Both of situations will continually reenforce themselves. Software teams working on easy to change software will find it easy to hit deadlines giving them extra space to worry about software quality. Software teams working on poor quality software will be perpetually scrambling to hit deadlines, think less about quality and their software will get worse and gradually harder to change. The end result of bad software without any intervention will be that the project needs to be scrapped and re-written. The end result of excellent software will be continuous addition of business value until the software lives it’s useful life.

4. The cost of bad software is invisible. All your scalable behaviors are enabled by software. Bad software scales bad behaviors and good software scales good behaviors. Your business is nothing but a sum of behaviors. What do I mean?

   Imagine a company that sells scrubs. There are several core behaviors that happen, the company orders scrubs, the company markets scrubs and the company reports on it’s performance. The company is a group of people coming together to do these things and if they stopped exhibiting these behaviors the company would cease to exist. The quality of these behaviors entirely drives the outcomes the company is able to achieve.

   Bad software will create bad behaviors. Imagine there is no error checking in the software the company uses to order scrubs. The company will either make more errors in their orders and not have a stable supply chain or they will spend more time double checking all their orders and have less time available for strategic work like maybe lowering the cost of their supply chain. Over an organization the sum of small inefficiencies created by software can easily go unnoticed all while silently choking that organization’s ability to be competitive. Conversly, organizations with high quality software are enabled to have more effective behaviors and are subsequently more likely to outperform.

TLDR

If you don’t want to read this whole page, that makes sense. Scan the contents and get a feel for if there is anything that applies to you or your organization. Something everyone should take away is first principles of work. Sometimes we get so caught up in theories of agile development, lean management etc. we forget what we’re all doing here.

Your goal as a manager is to find people who are smart, skilled and enjoy exercising their skills. Take those people and harness their skills in a way that they can create the most possible value for your organization.

This sounds obvious, of course, but sometimes we forget this is what it all comes down to. Obviously, this is easier said than done, or we would have thousands of management books describing how to accomplish this. But if all you do is keep that in mind and work tirelessly towards it, you’re already well on the path of creating an effective organization that will be productive and make employees happy.

References

This is not meant to be a comprehensive dive into every piece of running your software enabled business. Most sections in this work have entire books written about how to do them well. I’ll share a few here that I’ve found particularly helpful in thinking about digital product delivery and management.

1. Thinking In Bets - Annie Duke
2. Drive - Daniel Pink
3. Clean Code - Robert C Martin
4. Team Topologies - Manual Pais
5. First Break All The Rules - Marcus Buckingham
6. Lean Software Development - Mary Poppendieck
7. Accelerate - Jez Humble

I’m dedicating the first section to hiring. Why? For starters, you’ll probably find hiring difficult if you’re not running a cool software company. Beyond this, bad hires are very destructive to your organization. Even good hires brought onboard with wrong expectations can be exceptionally damaging. Every good team starts with great hires and a great hiring process. I believe so strongly in the importance of hiring that when I’m talking about implementing healthy team behavior, managing backlogs, etc. I often start with a quick discussion of hiring practices.

Let’s try an exercise. Think of the organizational problems you’ve had in the past in your career. Now try to find the ones that don’t relate to a bad hire or hiring process. I’d bet there are few. Maybe the team member didn’t have a core skill required to be effective, which was disruptive. More likely, the team member’s viewpoint on how to work didn’t align with your organization’s, their core drivers didn’t mesh with the organizational structure, or worse, they came into the organization with incorrect expectations. If someone comes in thinking they’re going to manage a large chunk of the company, and there is no realistic path for that, it will create dysfunction.

Hiring is often an afterthought in organizations. Bring candidates in, put them in a room with several top performers, don’t talk about it before, huddle after. If most people say yes, you tell the candidate whatever story you think will get them on board. If this sounds familiar, don’t be surprised if your results aren’t exceptional. This section should be helpful.

TLDR;

Hire smart people, who have a set of skills you need and who like exercising those skills. The single greatest screener for employees is whether they love the thing they will be working on. The revolution of creative work gives people the ability to do something they love as a job. Every piece of your digital delivery is something people already do without being paid. People love building software, love designing things and love thinking about improving digital products. Fid people who love doing these things, and you’ll be well ahead of most of your peers.

The problem with hiring starts with the fact that it’s much harder than we acknowledge.

There’s an underlying economic reason for this. The hiring pool is filled with underperformers. Why? Orgs are unlikely to let go of their star performers unless they have to. Star performers are also much more likely to be satisfied with their jobs. They climb the ranks quickly, carry high levels of organizational influence, and are usually working on things that impact their organization. The pool of people actively looking for a new job doesn’t contain top-tier employees.

This problem is exacerbated by the fact that interviewing is an unreliable process. Think of the times your team has all said a candidate was great, and they turned out to be at best mediocre, occasionally terrible. Pairing a large number of underperformers in the candidate pool and an unreliable interview process is a recipe for creating a mediocre team. Let’s look at some numbers.

The Numbers

Let’s start by defining the likelihood that a hire is either destructive or creates a competitive advantage.

There are 3 variables to consider.

C - The confidence that you’re hiring the correct role, and that you’ve defined the characteristics correctly. It’s very easy to think you need a role you don’t or to just not be right about the skillset needed to fill a role.

P - The percent of the candidate pool that matches the criteria you’re searching for

I - The likelihood your interview process will filter out an unsuitable candidate

The chance of a candidate not working out is 1 - (C * (1-((1-P) * (1-I))).

So, let’s say a destructive employee is bottom 20th percentile. The likelihood of hiring a destructive candidate in an average interview process might look something like this C - 70%, P - 25% and I - 60%. That leaves us with a roughly 50% chance of hiring a destructive candidate. Yikes! Now imagine rapidly growing your team; you very quickly fill your company with bottom quartile employees.

So what should you do?

It’s interesting to compare recruiting in sports to hiring in a corporation. Why? It’s easy for mediocre technology teams to pretend that they’re excellent, they don’t have objective barometers. Most teams I have worked with fall somewhere between okay to pretty good but every one of them believed that they were excellent. In sports, a team that doesn’t make the playoffs can’t pretend it’s exceptional. Moreso, hiring in sports should be much easier than hiring in a workplace. When considering an athlete, sport recruiters have years of film and analytics to go over and have people who are very good at evaluating talent dedicating 100% of their time to assessing candidates. Yet they still get it wrong.

Give yourself a break. If sports recruiters screw it up, how are you expected to get it right? Your advantage is that while a sporting team might need top 1% candidates to win you don’t. So if you consistently fill your team with top 30%th percentile candidates and do a great job empowering them, you’ll be off to a great start.

Four critical elements will improve your hiring process. They correlate with the three variables in the equation discussed earlier. First, improve your candidate definition. Second, improve your sourcing to bias candidates to be higher quality. Third, improve your interviewing to ensure you’re more likely to filter out candidates who aren’t a fit. Lastly, improve the candidate experience to make them more likely to accept with correct expectations.

I’ll dig into each of these aspects of hiring in the following sections.

The first step in any good interview process is to define what you’re looking for and gather the interview team to ensure they’re aligned. This is the most commonly missed step of the interview process. It results in interviewers asking duplicative questions and worse, missing interviewing for important candidate attributes while interviewing for attributes that don’t necessarily matter. The result of this process should be a list of skills and drivers you’re looking for in the candidates, and an idea of who is going to be looking for what how in each interview.

In this step, you’ll define the skills you’re looking for, and define the type of person you think would excel in your organization. Organizations tend to focus on skillsets in interviews and under-invest in figuring out if they’re hiring great employees. A candidate being good at the skill you need does not guarantee a good hire.

Spend a second identifying attributes that will make someone a strong employee outside of their core skillset. This should include their drivers, their aspirations, and their work styles. I want to examine two engineering archetypes for a second. Some engineers are driven by solving code problems and some are driven by solving user problems. I’m sure you’ve met both types. One will stay up until 3:00 am refactoring an excessively long class into more manageable code, and one will stay up all night building a new user feature they think will solve a significant pain point. Both may be very skilled and can be very additive to the right team, but both will also not be happy working on a team where they don’t get to express their unique superpowers.

Maybe you have a team where people like to get heads down for hours at a time and solve problems; maybe you have a team where people like to sit side by side and work collaboratively. All of these things matter in a hiring process. As part of your interviews, you may discover entirely new superpowers and drivers in candidates you didn’t know you wanted. That doesn’t make this activity any less valuable, going into an interview without a strong candidate definition is a recipe for a poor hire.

A few of the things I often look for in software engineers include

• Intrinsic motivation - Loves building software for the sake of software
• Highly curious - Spends time learning about software engineering outside of their job
• Strong team drive - Doesn’t want to let their team down and will do whatever it takes to make sure they don’t
• Loves digital product - Strongly motivated by software outcomes, not just the underlying technical pieces
• Good problem solver - Great at figuring out problems outside of their core skillset

This list, of course, can change on a role-by-role basis. It’s a worthwhile exercise compiling a list of the things you have personally found valuable in previous co-workers and determining if they fit a role you’re currently hiring for. If they do, consider adding them to your candidate definition.

By the time you’re done with this, you should have something like the following complete. Make sure to do this before any new candidate you bring in.

The critical observation in sourcing great candidates is that most active job seekers are not great candidates. Thinking back to the sporting example, what percentage of top-tier athletes are free agents at any given time? Most available athletes are, at best, role players unable to find a place on any roster. The implication here is simple, putting a job on a job board and waiting for applications will heavily bias your candidate base to poor candidates. Remember, good candidates are mostly fully employed. Base your sourcing strategy on two pillars: hiring promising junior candidates who will grow into tomorrow’s all-stars and reaching out to employed prospects.

Hiring promising juniors is the most challenging piece of a good sourcing strategy. These people will initially not be able to execute at the rate of a more senior candidate, and we ofter hire to fill immediate needs. Junior candidates help in two ways. First, as they evolve their skill set they can play various roles in an organization, so you don’t need to be as confident in the job requirements. Second, they’re not set in their ways. You can mold your behavior to however your organization is currently structured. Start by talking to local universities. University students who spent the last four years working in aligned disciplines will have four years of muscle memory under their belt and if you plan far enough ahead, universities are eager to place their students in good jobs. You can also look to local boot camps, but take these graduates with a grain of salt. They may be smart and have a skill set you can use but are three years behind the University grads at solving domain-aligned problems.

To recruit from other companies, use a recruiter. You can not recruit with an internal team as effectively as a recruiter can recruit for you. Focus on hiring out of companies you suspect have a strong discipline in the role you’re trying to hire for that have roughly similar team sizes. The goal is for your sourcing strategy to be as predictive as possible about the candidate’s ability to be successful in your organization. This is not saying that having worked at Amazon means someone won’t be productive in your 15 person digital product team, it’s just saying it is less predictive than having been successful in another 15 person product team.

Also bias towards people who have had at least one long stint at a company and had a number of title changes in that same role. It’s much more impressive to advance in an organization where everyone knows your skills than it is to convince someone you don’t know to give you a higher title. It’s also important for employees to see their decisions play out over a period of years. This long term feedback loop will help inform their behavior in new roles, including yours in ways you don’t get from shorter engagements.

This is where you determine if the candidate has the skills you’re looking for and if they’re a good fit. You should have gathered your interview team in the candidate definition process and defined what you’re looking for in the candidate. Take a second and craft an interview plan where everyone knows what they’re looking for and has some idea how they will elucidate it.

Skill-based interviews are simple, do some work with them. It amazes me how many interview processes don’t do this. You’re looking for someone who can do something specific, get them to do that thing. I like to spend 30-60 minutes doing it live with them, then leave them with some work to do on their own. No one can fake a live skills interview. If it’s a software engineer, solve a bug. If it’s a designer, make a quick figma component. Most of this should be muscle memory, and it should be obvious very quickly if they have the muscle memory. I’ve always regretted hiring anyone who didn’t perform well here. I like to follow it up with an assignment to get a work sample. Ideally make it something pertinent to your business and pay them for it. Try before you buy. These two simple things will make it abundantly clear if the candidate has the skill you’re looking for. You don’t need, and shouldn’t ask for, any esoteric problems, they’re not predictive of a candidates ability to execute on a skill.

Since we’re specifically talking about digital product teams, I’m going to include my #1 must do for interviewing software engineers, ALWAYS ensure they can read other people’s code. I like to do this by finding a basic bug or really simple feature in the codebase and getting them to solve it live with me on zoom. I generally pick something that co

To figure out if the candidate is a good fit and has the innate drivers you’re looking for. A few tips.

1. Ask open ended questions. If the candidate asks for clarification, tell them to fill it in however it feels right. Your goal is to not guide the candidate’s response at all. Their unaided response is indicative of their future behavior or their core drivers. When they give you the response, believe it and move on. You can use the time after the interview to come back and decide if what you’ve learned makes them a fit. How will you figure out what questions to ask? A fun exercise can be asking questions of your team, and figuring out which answers seem predictive. You know your best employees, how do their answers differ from the average employees? What could you have asked these people that would have helped you understand their potential in an interview? A few questions I’ll often reach for include:

• “Tell me about things you do gives you the most satisfaction in a job?” - This should let you know a little bit about their drivers. Software engineers may enjoy turning a mud puddle of code into a monet with beautiful factoring for example. But sometimes you’ll learn things that are a bit more non-job specific and can be really useful in understanding if this person will fit with your team. I once had a designer mention they love using design to manage stakeholder expectations. We didn’t hire her for reasons unrelated to the interview, but I imagine she’d be very effective at driving healthy relationships with non-technical teams, an invaluable skill.
• “What is something you do that you do better than everyone else?” - This is a question around a candidate’s self awareness. It’s It’s also the thing that as a manager you have to want on the team, because to unleash this person’t potential as an employee you’re going to hve to spend time getting them to lean into this skill. Let’s say an prospective designer tells you they’re really good at keeping people organized. Do you want or need this on the team? How would it benefit everyone if someone with exceptional organizational skills joined the team?
• “What frustrates your co-workers most about you? What kind of person complements you really well to mitigate this?” - Great employees know what bothers their co-workers about themselves. Sometimes they’ll go so far as to ask. They also know how really effective coworkers on their team will help make them more complete in turn.
• “What makes someone a really effective manager for you?” - Good employees know what they like in a manager, and it’s useful to understand if you can fill that role. Everyone has different management styles, and yours may not match the drivers of a potential candidate. If that’s the case, it’s going to be much harder to get their best work out of them. If you are laissez-faire and the candidate values frequent direct feedback, you may both end up frustrated. Conversely if you love frequent direct feedback and the candidate likes space and guidelines to work, that candidate will be often annoyed an unlikely to product at their best.
• “What’s something you don’t like doing and would prefer not doing in future roles?” - It floors me how often someone will respond by saying they don’t want to do the exact thing I’m hiring this role for.

2. Ask for specific examples of behaviors. Listen for quick responses with highly specific details. General answers or slow answers aren’t bad, but won’t help you understand how the candidate is going to behave in the future. If a candidate cares about something, and frequently exhibits a behavior it will be top of mind. I always ask how candidates handled a conflict situation in their past. I don’t consider a response that’s theoretical, general or slow to be a disqualifier, just unhelpful in assessing the candidates strengths. If the candidate is able to provide a specific example, ask for another one. People who exhibit consistent consistent behaviors that they value will have multiple top of mind.

Examples of useful questions.

• “Tell me about a time you had a disagreed with a co-worker. How did you resolve it?” - Great employees will disagree with their coworkers.
• “What’s an example of a time you went above and beyond to create a really positive outcome for the business?” -
• “Tell me about a time you changed your opinion or made a mistake and learned from it” - Lifelong learners will have lots of these. You can push for a second or even a third and if they can offer them that’s a really positive sign.

3. Ask consistent questions. Over time you’ll learn of their predictive power.

1. Build from the draft: The value of getting good candidates out of university can’t be overstated enough. They come in with expectations around roles that can be managed easily and you can teach them to work in a way that works with your organization. As a manager growing a team, you should make it a priority to reach out to local universisties and make some friends there.
2. Work with an external recruiter: If pool of people actively looking for a new job isn’t that great where should you turn to get great candidates? Other companies. External recruiters can provide you access to candidates outside your network in these companies. Even highly satisfied star-performers have bad days, and one message on a bad day from someone they know is all that’s needed to get a conversation going that might move that person over to your team.
3. Design a recruitment process that impresses candidates: There’s nothing worse than finding a candidate you love and then have them reject your offer. Great interview prcesses impress great candidates. They should be fun and demonstrate that your team is full of people they want to work with.
4. If they’re a software engineer, take the opportunity to make sure they can read code: There are alot of things you might look for in a software engineer. This is the only non-negotiable. Spend a second making sure they can work in other people’s code. The easiest way I’ve found to do this, is have them solve a simple bug in your software. You’ll be amazed by the difference in how quickly top performers and poor performers are able to negotiate a codebase and find the source of a problem.
5. Make sure you’re very clear with expectations: Never promise titles, organizational influence or career paths you can’t follow through on. This is the most destructive thing you can do in an interview process, and if you’ve designed your team thoughtfully, you won’t need to.
6. Know what you’re looking for: Don’t just send team-members into interviews. Before you interview someone, be clear on what you’re looking for in a candidate, and how you plan on learning whether the candidate exibits those characteristics.

If you talk to a person on any software team about how they behave they’ll probably tell you they do “Agile Software Development”. Almost all of them probably do sprints, have sprint planning and use an agile board, most assign points to tickets, and some probably have grooming meetings. You’ll note that this hasn’t made every single software team exceptional. Why? The rituals of “agile software engineering” do not in and of themselves make teams good. Agile rituals without the core essence of agile can actually make teams worse.

Having said that, the core elements at the center of agile can help make your team better. I’m not going to go through a deep description of agile software engineering here. Wikipedia can do that for you. I will examine some principles that I think are important and should help set your team on the right track.

Key features of agile development

• Limits on work. Either the amount you’re working on in a period or the amount of work you’re working on at once.
• Teams that are self sufficient to solve problems. When presented a problem to solve, a team should not be blocked by work required outside the team.
• Frequent product delivery. Teams integrate quickly

What this accomplishes

It Encourages Solving Problems

Frequent delivery encourages solving problems. First, each iteration should hypothetically solve some sort of business problem. Otherwise what was the point of the iteration? Yhe team may as well have stayed home. Second, it surfaces problems faster. It’s impossible to know how customers will use software without giving it to them. Lastly empowering the team to solve problems allows for more discusion around problem resolution

Focus

One of the magical things about agile is it encourages teams to focus. There’s nothing that destroys a team’s ability to execute like not focusing. Whether it’s context switching, resource contention or other, teams working on too many things at once

Self Sufficiency

As orgranizations grow, organizing the organization becomes harder. It’s hard when a few people on a team don’t have the same priority, two teams with different priorities, forget about it. Even just identifying a simple project requires two teams is a reason to add an extra sprint.

Why agile works

There’s a lot of theory to be found about why agile works. It’s surprisingly not all very aligned. Before digging into where I see key advantages in agile, it’s worth noting that effective agile behavior is fun. It empowers everyone to participate in problem solving and creates momentum by continuously delivering improvement. All theory aside, there is something about people taking joy from their work that helps teams deliver better outcomes, and great agile behavior should help your team really love what they’re doing.

• It empowers smart people to solve problems. Most really capable people I know are great problem solvers. Great problem solvers are not motivated by implementing someone else’s problem solution. I actually think this may be the single most impactful outcome created by an effective agile process. Think about it yourself. When you’ve worked on a project you were excited about you’ve probably knocked it out of the park. When you work on a project you don’t care about the quality at the end is worse, and it can take 6x as long or more.
• It reduces risk through delaying decision making. Many of the most most interesting choices I’ve ever made were not initially obvious and maybe didn’t even seem available at the beginning of a project. By continuously re-evaluating rather than having a pre-defined project plan we can take advantage of emergent opportunities. Delaying decisions is one of the most powerful tools you have to create better decision outcomes, you should always be learning about your business and have more information when the time comes to make the decision.
• It reduces risk through frequent delivery. One of your largest software risks is building the wrong thing. Not only is the cost high, the opportunity cost can be insurmountable for early organizations or for organizations that are tight margin. By delivering software frequently you can know and not theorize as to how it’s going to impact it’s target customer.

Do I have to “agile”?

It’s blasphemy in the world of modern software engineering to not “agile”. This means that everyone says they’re doing agile software development. You don’t have to agile. Say it with me. “I don’t have to agile”. Many organizations that call themselves agile actually miss every single key feature of agile. Don’t do this, pretending to be agile won’t make you more effective. If you want a group of product managers to solve problems and spoonfeed an engineering team, you can do that. You’ll even need cheaper engineers.

Before anyone sits down to actually build software, digital teams are first presented with the job of figuring out what to do, and when to do it. This process usually involves the organization setting goals, a set of product managers breaking down the goals, looking for opportunities and presenting some sort of roadmap to the organization. Some variation in this activity happens in every company. How this actually plays out though can vary dramatically company but generally falls into two different types of delivery planning, product based delivery planning and project based delivery planning. Understanding both types of thinking about your digital activities and when to apply them is critical to building a successful and competitive software organization.

Let’s start by thinking about our goal in building a digital product. We want to solve customer problems for which they will pay us; we call this delivering value. Ideally we deliver so much value at a low enough price that customers can’t help but use the product. When some group of users exists for whom this is true, we say we’ve found product market fit. As we continue to add value and reduce cost (And market our product of course) we should hypothetically grow and retain that user base.

I live in Los Angeles. In LA, due to the size of the city and poor urban planning, it’s very hard to live without a car. Despite the fact that a car is expensive, it delivers enough value that most people in the city have cars. This is how you want your product to be, can’t live without. You do this by making some set of features in it so valuable to some set of customers that it’s indispensable.

Some astute readers are probably thinking something along the lines of “I guess that makes sense… But it’s kind of a weird way to think about integrating our new accounting software last month.” Good point. Maybe if you do some mental gymnastics think of your accounting team as the “user”… But really probably the most important things in your new accounting software was that it matched the spec at the end and it was delivered on time. You’ll notice there is a shift in what you’re looking for here, you’re actually looking to maximize predictability in what was delivered and when it was delivered. This is the core difference between project thinking and product thinking, both are trying to create business value, but in different ways. One aims to create business value by maximizing customer value, the other by creating predictability of delivery.

Project Thinking

I’ll start by discussing project thinking because it’s what we’re most used to. Start by thinking back to a group project you worked on in university. It probably had a deadline, and if you didn’t hit that deadline you either were severely penalized or took s 0. There were probably also a set of requirements that needed to be met at the end to get a good grade.

A common computing science group undergraduate endeavor is writing a compiler. The group will be given a set of instructions that must be compiled and multiple test cases that they should use to ensure their compiler works. On the first day of the project the group knows the requirements of the project (Compile these 14 different instructions) and the deadline (You must submit your solution.) A situation with a known set of requirements and a known deadline is called a “Project”.

In order to successfully deliver your project you probably started by putting together a plan that looked something like “Jenn will do A, B and C. Josh with do D, E and F. Then we’ll get together and put these things together and once they’re together Jenn will take on G and Josh will take on H.” (Where letters could really be any task associated with the project delivery.) You may even have been asked to model the project delivery using some sort of project planning tool like a gantt chart.

Delivering software in this way makes intuitive sense. Most of us have succeeded to some extent in our lives by virtue of having a strong capability of delivering projects successfully. We see this type of delivery around us all the time as well. It’s how people build house, and bridges and warehouses. Predictability in delivery is also very comforting as an organization. We like predictability and it feels safe to say things like “In six months we’re going to roll out a new bundle management interface.” In fact it’s often necessary to have predictable delivery to support an organization. Imagine moving to a new accounting software as described above. We probably ended the contract with our old accounting software, and we need confidence that we can predictably launch to new accounting software at the time the old accounting software is turning off. We need to have confidence we can integrate with partners on timelines set out by contracts. We need to be able to predictably have software ready for big marketing pushes we have around launches. etc.

In all these scenarios the predictability of our ability to deliver on time trumps all other concerns, and project based delivery is the right way to think about delivering your software.

Product Thinking

That sounds great, why would I not want predictable delivery? It’s that predictability is bad, just that often we want to optimize for a different outcome. Recall that our customer uses our product because it delivers value. As we work on our product we should be adding to the value it’s able to deliver to customers. If our goal is to do a better job of delivering value than our competitors, we want to optimize the rate that we are able to increase the value our product delivers. This is the pace of value delivery (Δv/Δt). It’s easy to understand how an organization that continually delivers value at a faster pace, will end up with a better product. Before digging into why optimizing the pace of value delivery is at odds with optimizing the predictability of software delivery I want to talk a little bit about games.

When I was going to University there were two major game research departments in the computing science department at the school, the checkers research department and the poker research department. Really there wasn’t a checkers department, but there was at one point and they solved the game of checkers. In checkers there is a perfect move for every possible board configuration. For black there is always a perfect move to win, and for red a perfect move to stave off inevitable defeat for as long as possible. This is possible because checkers is what’s called a complete information game. We know the entire state of the world at any given time, and so we can make decisions that are provably correct with 100% confidence that they are correct. Because of this, we could lay out a strategy of provably correct moves before the game, never change the strategy and win every time. (Assuming we’re red of course.)

Poker is different, it’s what’s called an incomplete information game. We don’t know the whole state of the world, because we don’t know our opponents cards. At any stage of the game, decisions we make cannot be made with 100% confidence, we have to decide how confident we are based on the cards on the table and our opponents behavior. Every decision we make in poker is a bet on the state of the world. If I get pocket aces I start out I probably start out betting that I have the best hand and raise and re-raise pre-flop. If the flop shows a suited ten, jack, queen and an opponent bets heavily on it, I may consider folding my pocket aces, because I am now betting someone else has a better hand than me. The key to successful behavior in an incomplete information scenario is rapidly revising our strategy as new information becomes available. Imagine setting a betting strategy at the beginning of a hand and not revising it when I see the flop, you’d lose a ton of money. In fact, in this scenario the best strategy may be to fold.

In product management as in poker, we are continually gathering information about the world around us. We talk to our customers, see user behavior, learn more about our competitors, meet new prospective partners and the list goes on. Every feature we build is a bet on the amount of value the feature will deliver to customers based on all the available information at that time. It’s important to note that completing a feature does not automatically add value. In fact, too many ill-conceived features detract from customer value. Think of the adoption of figma vs photoshop for UX design. Sketch and figma took photoshop, the de facto standard for web design circa 2010, removed 95% of the features and created a much better product.

In a scenario where the majority of features we’re delivering are bets on delivering user value, and where we’re continually gathering new information, project thinking guarantees we’ll be working on features that are not the highest value because the bets were taken at a point where we had less information about the world. Much like the poker player who starts with pocket aces who opted to fold, we should continuously re-evaluate our confidence in the bets we’re making in order to deliver the most value. However, that re-evaluation significantly reduces the predictability of when (or even if) we’ll deliver a feature. This is what makes product thinking so hard, rather than saying “in 6 months we’ll deliver a new bundling system” we have to say “in 6 months we’ll have maximized the value we delivered to users.” We’ll talk more later about how to actually implement product thinking in an organization.

When to use project thinking or product thinking

At most large software companies, the answer isn’t interesting. They have digital product teams that are innovating on customer products and they use product based thinking and delivery. They also have software service organization that do things like integrate ERP software and they use project based thinking and delivery. For smaller companies that are not explicitly software companies, that’s a luxury that’s normally impossible. These organizations have more “Kitchen Sink” style software teams where the teams must handle all different types of outcomes the organization needs to drive. In this case it becomes more important to be thoughtful about the type of delivery going on.

It should be clear now that both delivery strategies aren’t well suited for the same sorts of tasks, so when do you use each? Let’s look at some examples.

1. I’m opening a new warehouse on January 15th, and we need our e-commerce platform and ERP connected to it. - Project thinking. The end deliverable is well defined, the scope is easy to predict and there is an end date that is critical to hit.
2. We have a grocery list app and we’re trying to be top in the app store - Product thinking. We don’t know the most valuable thing that will make our app better than competitors.

So, what’s the difference? There are three things to look at when deciding how to behave.

1. Scope - Can the deliverable be broken down into smaller deliverables? Imagine a project that’s going to take months to get done, and unless it’s fully complete it won’t deliver value. The greater the scope, the more likely you should use project based delivery mechanism. This is not an excuse to take your 6 favorite features, lump them into a large scope “project” and plan for delivering them on time.
2. Commitment - How committed is the organization to deliver this feature? Maybe you’ve already invested millions of dollars in a new ERP, or there has been months of marketing push around a new feature. In these scenarios, timeliness of delivery matters more than pace of value delivery and you should use a project based delivery mechanism.
3. Confidence - How confident are we the feature we’re building will deliver value? If this is less than 100% (And in most cases it should be) we should favor product based delivery. What do I mean by confidence? Say we’re integrating Salesforce CRM to SAP ERP, we certainly need something that lives in the middle and translates domain objects between the two systems. I’m 100% confident that feature will deliver the required value. On the other hand if I’m operating a wellness facility I may want a customer dashboard that shows the customer what time their upcoming appointments are. I suspect this will deliver customer value, but I can’t be 100% confident it’s something my customers want.

It’s very likely that your organization will need to operate in both ways. We’ll dig more into how to implement strategies to do this later on.

Can I use product thinking outside of digital product?

Yes, reading this you may have noted that the circumstances under which product thinking is effective exist in other places in your organization. For example, product based thinking can be particularly effective in marketing. The landscape is always changing and we don’t know what initiatives are going to work. Like digital product, we like to think of our marketing spend as predictable and plannable, but if we plan too far out we ignore emergent opportunities and things we learned from previous initiatives. If this resonates, you can also use all the management tactics described here to drive your marketing and growth behaviors.

• My team understands “True North”. They know the philosophy around which they should be making choices. They know the long term vision for the company
• My team solves problems rather than implementing solutions.
• My team understands why they’re working on the things they’re working on
• My team’s ideas make their way to a place where they can be acted on

Sneak Peak: Mostly buy.

Software is expensive. Like, really expensive. It’s common for a piece of good software in your stack to cost on the order or $80,000 per year or more.

Does it create competitive advantage/differentiation?

If a feature is designed to create a competitive advantage for you, there’s a pretty good chance that buy is not on the table for you. If you could buy it, your competition would have it, and it wouldn’t be a competitive advantage.

When Honest was founded there was not good subscription commerce software on the market. Honest built the subscription commerce software itself and enabled the company to grow from 0 to 300 million in revenue in under 3 years. This would never have been possible without the subscription commerce software.

Competitive advantage doesn’t have to come from features that don’t exist in other products on the market. Login is a table stakes feature for almost all software at this point. Slack however made an extremely simple login passwordless flow that decreased friction and increased product adoption.

If your feature isn’t creating competitive advantage it’s very likely that there is a software product on the market you can integrate. The off the shelf software will know the problem space better than your team since they spend all their time thinking about it.

The true cost of projects

Say you scope a new feature. It’s going to take your team about 2 months with 2 engineers to complete the feature. A good engineer on the West Coast will probably have a total cost of about $180,000 per year. The engineers themselves will cost $30,000 to complete the project. Add to this the cost of QA, product management, and project management and your cost to build (If you can maintain your timeline, this may not be the case) is $50,000. Worse it’s not uncommon for projects to dramatically exceed their scope. (If you’re reading this guide hopefully this happens to you a little bit less common.) I’ve seen many projects that were meant to run for 2 months go on for 6. All the sudden the project cost $150,000 plus a whole lot of opportunity cost and organizational distraction.

Now you need to maintain this software. You’ll need to update packages for security flaws, you’ll need to maintain infrastructure, you will absolutely need to make changes to the feature. The software company can maintain it’s software cheaper, because they amortize the cost of the engineering across all their customers. But, it’s not just a dollar cost. It’s organizational focus. Having to focus on these changes and infrastructure will prevent you from focusing on the things that make your organization exceptional.

The modern software ecosystem

Something new in the last few years (2018-) is that almost every piece of software you need exists off the shelf. Need auth? Auth0. Need to integrate? Zapier. Remember this when setting off on creating software.

The two activities of an organization

Everything your organization does falls into the category of “Making Decisions” or “Executing on Decisions”. The focus of organizations often strays to improving execution, while failing address decision making. First we’ll examine a few of the negative organizational byproducts of poorly executed decision making, then we’ll look at some of the reasons that organizations fail to do a good job of decision making; finally we’ll talk about what to do to make decision making better.

Why is decision making important?

Your organization is a sum of decisions you’ve made. Probably some of them were good, probably some of them were not. It should be obvious that if we’re able to bias the decisions towards good decisions the organization will be better off. What we don’t realize is the infrastructure around making decisions will not just impact the quality of decisions, but also the happiness of employees and organizational effectiveness throughout the decision making process. Almost every real decision that needs to be made will lead to some sort of employee disagreement, and good behaviors around making the decisions will make those disagreements much easier to handle.

How to know if you have a problem with decision making

Every organization I have ever talked to has an issue some issue with making decisions. Decision making problems in organizations are easy to spot, but are rarely acknowledged because no one looks for them. If any of the following applies to your organization you probably have an issue with decision making that you need to address.

1. Members of the organization frequently complain about decision making.

   This might sound obvious. People are complaining about decision making, so we have a decision making problem, right? As a leader, you can be completely oblivious to this unless you actually look, because the symptoms are hidden from organizational leaders. The way this manifests is people standing around in the kitchen will say things like

   It’s so stupid that we’re changing the facebook landing pages to client side rendered pages.

   An organization that is good at making decisions will minimize this kind of conversation.

2. “Decisions” are not followed through on

   Decisions made through broken decision making behavior are much less likely to get executed. They will lack the organizational and team buy-in to make them actually work out.

3. Members of the organization complain that other’s are “in their lane”

   No matter what you do this will occasionally come up in your teams. This manifests as people saying things like

   I’m the director of data science, and the the database schema for this project is terrible. No one talked to me about it and it should be my call.

   Having “Lanes” should be the first red flag for you. An organization that understands decision making doesn’t need to be nearly as black and white in terms of who owns what. There’s no reason the director of data science mentioned above should have to be the person who decides on the database schema for a project. In fact, this project may not be the director of data science’s main priority and requiring them to make the decision will slow down the project. Rather than making sure that everyone stays in their lane, we solve this problem by following good decision making behavior.

4. The reason your managers are giving for doing something is “Because so and so said so”

   Any time ay employee is discussing the “why” behind a decision they should understand the reasoning, even if they don’t agree. Saying “We’re doing this because Jeff said we have to do this” is destructive and usually caused by broken decision behaviors.

How to make decisions

1. Identify that you’re making a decision

   The fact a decision is being made is, sometimes, obvious. For example “Are we going to change from a homegrown software platform onto a turnkey software platform?” or “Are we going to use SQS or RabbitMQ for our queueing system?” Often, however, a decision being made slips through the cracks. For example you marketing team might set up a new facebook campaign that drives to a landing page that hasn’t been used for marketing before. Maybe the lander wasn’t meant to receive marketing traffic so the UTM parameters aren’t set up correctly, or maybe it’s just slow. Deciding to send a campaign to a new lander is the kind of decision that often goes un-noticed but that can cost an organization both in dollars and organizational trust down the line.

2. Identify a person to make the decision

   For every decision identify someone in the organization to make the decision. Groups are not well suited to making decisions. As a leader, It can be scary to surrender control over meaningful organizational choices. Remember that you’ve hired people because you trust them and they’re good at their job! More importantly, you may not be the best person in the organization to make the choice. Front lines employees usually have more information and by being closer to the actual problem are better able to understand constraints.

   How do you identify the correct decision maker? Ideally you want an employee as close to the problem as possible, but with enough organizational influence that people will buy into a choice they’ve made.

   Imagine a company that manages software architecture. Something like Heroku. The founder/CEO is likely and excellent software architect and probably very good at devops. The organization will have devops problems and need to make decisions on them. Despite their apparent skillset, the organization’s CEO is not the right choice to make decisions on the devops problems, the CEO probably doesn’t spend nearly enough time in the weeds of your company’s tech stack to make a good decision. On some specific decision like how to fix some sort of persistent deploy bug one of your developers with good social influence in the organization would be an appropriate decision maker.

3. Make sure the person making the decision understands their framework and constraints

   One side-effect of pushing decisions down to the frontline is that the decision maker will naturally have less context. This means that it’s important that the organizational goals and contexts are communicated.

   Let’s talk again about the Software Architecture organization. The CEO is an exceptional architect, but the CEO is not the most appropriate decision maker. It would be unwise to ignore the CEO’s experience. There is a good chance that the company’s CEO has a direction they want the team to move in. For example, maybe the CEO knows that the team will need to remain small based on budget, so they want to keep the surface area of different technologies minimal. If the decision making developer decided to fix the problem by introducing a new technology, then there has not been effective communication of the companies goals and the constraints the decision maker needs to work within.

4. Have the person making the decision identify and talk with all key stakeholders

   You’ve identified the decision maker and given them a set of constraints. No matter who the decision maker is, they will not have the full picture. Also, key stakeholders need to be involved in decisions to create buy-in. Your decision maker needs to talk to each stakeholder to understand their opinion and the reasons behind the opinion. The decision maker listening to each stakeholder will not only enable them to make a better decision, it will allow them to address any concerns the stakeholders will have if the decision does not go that stakeholder’s way.

5. Make the decision

   As a leader, you’ve identified a decision-maker, you’ve made sure they understand the constraints, and they’ve talked to all the key stakeholders. Let them make the decision. This is why you hire people you trust who are good at their job. Be thoughtful about it, but unless it’s a disaster of a decision, go with it. Remember, at this point they should know more about the problem than you do.

6. Communicate with all key stakeholders what the decision is and why the decision was made

   The decision, now made, needs to be communicated out. If you’ve built a diverse organization not everyone will agree with the decision. This results in problems at organizations that have not followed an effective decision making process. If you’ve done everything right up to here, you’ll be fine. Everyone understands who’s decision it was to make and the framework within which the decision was made. Now you need to communicate to each stakeholder what the decision was and as importantly why it was made. Since the decision maker has talked to each stakeholder they should know each stakeholder’s concerns and be able to effectively address the concerns.

7. Review

   Any decision should get a retrospective that is blameless. Decisions will occasionally be bad or wrong, that doesn’t make the decision-maker an ineffective employee. This is an opportunity to get better as an organization. Don’t miss it by blaming. Do take the time to scrutinize whether stakeholders were all consulted, the framework was passed to the decision maker, and the reasons were effectively communicated out.

How to implement a decision making process

All of this can be implemented without new “enforced processes” and without new stakeholder meetings, decision meetings etc. Rather it should become an organizational habit. For example in step 4 “Identify and talk to all stakeholders” the decision maker could accomplish this without having any large meetings, or passing through and “process gates”. They should understand what’s expected of them and all conversations can be handled 1-1 or on slack.

Implementing this playbook is easy. First, share the playbook. Second, pick a decision and run with the playbook. Third, have a retrospective on how it went. Rinse, lather, repeat. If you and your managers continually decide to push effective decision making it will become an organizational habit.