Small Business Programming

Learn how to be a wildly successful small business programmer

What you should know about the Effective Executive: part 5

This post is part of a series on The Effective Executive (by Peter F. Drucker). You can find the first post here. In this post I’m going to tackle chapter 6: the elements of decision-making.

Chapter 6: the elements of decision-making

I had a hard time getting my head around this chapter. I’ve read it several times over the years and I’ve always glossed over it with the takeaway that effective executives make important decisions by following a decision-making process. Beyond that, my eyes kind of glazed over. I’ve encountered so many decision making processes over the years and they all have failed me in one way or another.

But since I committed myself to writing about this chapter in this post, I dove into it and I finally think I understand what Drucker was trying to tell us.

Overview

Effective executives make decisions of consequence for their organizations. They do not make a great many decisions but they follow a five step process that establishes a rule or policy that addresses the issue at the highest possible conceptual level. Once you make a decision it is not considered complete until it has “degenerated” into someone’s job and it has a feedback mechanism.

Step 1: is this a generic situation or an exception?

The first step is to determine which of four situations you are in:

1. truly generic – all the “problems” are just symptoms of the underlying condition

Until you address the underlying condition the symptoms will not improve. For example, I had a situation where my VM was crashing randomly, I was getting weird reboots, and my GIT repo became corrupted. At first, they all looked like unrelated problems. I wasn’t able to diagnose or eliminate these problems until I realized that they might be linked. I tested my RAM and learned it was faulty. That was the underlying condition tying those seemingly unrelated events together. Once I replaced my RAM (and repaired my repo), my problems went away.

2. a unique event for your company but it is actually generic in business

Examples might include deciding to migrate to the cloud, handling a merger and integrating multiple IT systems, or responding to a data breach. These might be unique events in the history of your company but they are quite common events in business.

3. a truly exceptional and unique event

This is an truly unique event without comparison in the history of your business or any business. Drucker mentions the thalidomide birth defects tragedy as an example. A parallel in programming might be the complexities and challenges of deploying self-driving car software. There’s no real template for the legal, ethical, social, and technological challenges of releasing that kind of software.

4. an early manifestations of a new generic problem

If you deploy machine learning-backed pricing bot you might start to see a whole new classes of problems such as:

  • pricing bias/discrimination (illegal pricing strategies adopted by your bot)
  • price manipulation by competing bots (bots manipulating your bot)
  • sub-optimal pricing (your bot fails to outperform humans)

Bad things might even happen to you if a major competitor adopts a pricing bot. You might suddenly find your pricing strategy is ineffective even though nothing has changed inside your company.

An example

You have inevitably struggled to read code other programmers have written. For example, people write overly complicated code or write in an unfamiliar style or with unfamiliar formatting. Lots of teams descend into endless arguments over the acceptable naming standard, white space formatting, programming paradigms, language features, etc. And the whole tabs vs spaces debate is alive and well.

Drucker would encourage us to solve this problem at the highest level possible. In PHP you can simply adopt the PSR standards. And you can even setup your IDE to automatically format your code in that standard. At my company we used a modified PSR standard. Our IDEs automatically format our code before every commit. And we have a couple static analysis tools that flag things we don’t want to see in our code base.

Anything you can do to avoid negotiating every detail of how your code looks or the language features you use is a win in my book.

Summary

Drucker argues that you must handle truly unique events (situation 3) on a case-by-case basis. Everything else requires a generic solution, a rule, a policy, or a principle. Once you have established the right principle, you can handle all manifestations of the generic situation pragmatically.

Step 2: develop a clear specification of what the decision must accomplish

How are you going to identify a solution that satisfies all your needs if you don’t know the boundary conditions of the solution? The short answer is that you can’t. Unless you have a clear understanding of the boundaries of an acceptable solution, you won’t be able to tell when a plan will solve the problem.

An example

This makes sense. If your boss says that he wants your website to be faster but doesn’t give you any other guidance, how will you know what actions will satisfy “faster” in your boss’s eyes? You probably need target average and worst case response time targets at a minimum. You may also need to get your boss to set a limit on this project.

Without knowing the boundary conditions of an acceptable solution, your solution space is unacceptably large. Should you rewrite your website in C? Add a caching layer, dump your ORM and write raw SQL queries? Optimize your images? Serve your images from a CDN? Split your database from your web server? You won’t have any idea which–if any–of these solutions will solve the make the website “faster” problem.

Step 3: stick with what’s right rather than what’s acceptable

I can’t say this any better than Drucker:

One has to start out with what is right rather than what is acceptable (let alone who is right) precisely because one always has to compromise in the end. But if one does not know what is right to satisfy the specifications and boundary conditions, one cannot distinguish between the right compromise and the wrong compromise–and will end up making the wrong compromise.

Need I say more?

Step 4: convert the decision into action

Here’s more Drucker:

In fact, no decision has been made unless carrying it out in specific steps has become someone’s work assignment and responsibility. Until then, there are only good intentions.

How often has your boss said “From now on we are going to do x” only to have that decision last a couple of weeks (at most)? How often has some policy or initiative you’ve tried to implement followed that same path?

Drucker has some advice for us. Converting a decision into action requires we answer the following questions:

  • who has to know about the decision?
  • what action has to be taken?
  • who has to take it?
  • what does the action have to be so that the people who have to do it can do it?
    • the people assigned have to be capable of the task
    • make sure measurement, standards for accomplishment, and incentives are changed simultaneously otherwise people get caught in paralyzing internal emotional conflicts

If you can’t answer these questions, you might be in trouble.

Step 5: build feedback into the system

Drucker stresses that effective executives know they must go back and look at the results for themselves. It’s not enough to make a decision and communicate it to the appropriate people. You need to actually go look at the results yourself because that’s the only way to get reliable feedback.

It’s also the only way to see if the assumptions underlying the decision are still valid. Managers who fail to perform this step are the typical reason for persisting on a course of action long after it has ceased to be appropriate or even rational.

An example

I worked as a solo programmer for many years. But at one point we needed more programming than I could provide so we hired a second programmer. I gave my new co-worker a few assignments and sent him on his way. Big mistake. We tried again but this time I gave my new co-worker more explicit instructions and gave him the opportunity to ask many more questions about the task. He still missed the mark. It took us a long time to make code reviews our policy. Code reviews were the only way we could ensure that all new code we wrote met our standards. Code reviews are the programming equivalent of “going to look for oneself.”

Now that we’ve made code reviews part of our culture, we are trying do more unit testing, which is a great form of fast, automated feedback.

Wrapping up

I’ve never practiced the decision making process Drucker advocates in this chapter. I find Drucker’s advice to be practical in a lot of ways but it somehow doesn’t fit with how my mind works. I don’t naturally try to figure out if I’m faced with a symptom of a generic situation or an exception, even if I can see the value in solving a problem at the highest conceptual level. The “5 whys” analysis technique fits my brain better.

I also get the feeling that Drucker envisioned people using his framework to solve bigger problems than I typical face. Drucker’s examples are from situations faced by famous CEOs, military generals, and American presidents.

So your mileage my vary. Read the chapter if Drucker’s decision making process sounds interesting to you. Or skip it and know that all the other chapters are still very applicable to small business programmers.

What you should know about the Effective Executive: part 4

This post is part of a series on The Effective Executive (by Peter F. Drucker). You can find the first post here. In this post I’m going to tackle chapter 5: first things first.

Chapter 5: first things first

Effectiveness is all about concentration. You will achieve your maximum effectiveness by doing the first things first and doing only one thing at a time. Let me explain. If you are trying to maximize your contribution you will find there are always more important contributions to be made than time available to make them. Furthermore, your “major contributions” are no minor tasks, they require all your concentration and strength.

Interruptions, phone calls, meetings, emails, and multiple priorities, especially multiple priorities, disrupt your concentration, fragment your time, and slow you down. I can’t state the importance of doing one thing at a time better than Drucker himself:

This is the “secret” of those people who “do so many things” and apparently so many difficult things. They do only one at a time. As a result, they need much less time in the end than the rest of us.

How to get more time to focus on the things that matter

You need to ruthlessly cut all activities or efforts that are not producing results. How many things are happening in your company because “we’ve always done it that way” or somebody thought it would be a “gold mine” but it turned out to be a “money pit”? If you wouldn’t start that activity again today, it probably has to go. You can’t continue to add tasks to your to-do list indefinitely. You need to cull activities to free up resources and people to go after new opportunities.

With that said, it might not be so easy to cull something that is no longer productive. Drucker warns us about “sacred” projects. Don’t let that stop you from trying to cull them, just realize that you might be in for a fight.

I tried to have one such project culled. It’s one of those things you have to see to believe. Our general manager agreed that we should kill the project to free up resources to pursue better opportunities. But he and I were overruled by the owner who started it. We tried to cull the project again a year or two later and he overruled us again. The best we’ve been able to do is push it into a corner and try to minimize the time and resources devoted to it.

How to identify priorities

Drucker has four rules for identifying priorities:

  1. pick the future as against the past
  2. focus on opportunities rather than problems
  3. choose your own direction–rather than climb on the bandwagon
  4. aim high, aim for something that will make a difference, rather than for something that is “safe” and easy to do

I’m sure you can think of lots of ways to apply these rules to programming. Let me give you just a couple of examples from my experience.

Pick the future as against the past

This shows up in lots of ways.

As our customers get faster internet connections we worry less about total page size and rendering time on dial-up and slow computers, which was once a major consideration in our website design.

We have a ton of “legacy code” and we’ve been fighting with it for years. We also have a long list of features we would like to add to our systems. We’ve tried various strategies to help us strike a balance between cleaning up our legacy code and adding more features. One of the things we tried was refactoring sprints. They were painful; progress was just so slow. These days we try to prioritize opportunities rather than problems by adding new features when we can and clean up old code only when their isn’t any way around it. We hold new code to a higher standard than old code. That seems to give us the best ROI of anything we’ve tried.

Focus on opportunities rather than problems and aim high

I’m always trying to calculate the ROI of the code people want us to write. We can’t figure things out to the dollar but we can get things more or less in order and that’s good enough. I’m convinced that there are whole classes of problems that aren’t worth addressing with new code.

For example, we have a warehouse where our staff do order fulfillment. The process isn’t as fast as it could be and we often receive requests for code enhancements to make things go faster. The problem is that the cost of staffing and running the warehouse is actually quite small. We only pack orders for 11 weeks in the spring and most of those workers are temporary hires at relatively low wages.

Do you see where I’m going with this? Even if we could make the warehouse operate with zero staff, the total amount we can save is limited by the cost of running the warehouse (it can’t go below zero). But there is no practical limit on how much we can boost revenue. So as long as our system constraint isn’t in the warehouse, it probably doesn’t make sense to invest programming effort there.

Choose your own direction

I once read this article by a business owner who justified waiting a couple of years before adopting new technology. He used wifi as an example (this is a very old example). He said he could rush out and buy all that new expensive gear and have people running around trying to figure out how to install it and get it all working. Or he could just wait a year or two, let the prices come down, let someone else work out the kinks, then hire someone who had successfully installed many wifi systems more complicated than he needed. That way he would be relatively certain he would get a working system at a low price.

I was impressed with how much sense his strategy made. So we’ve done the same thing with our stack. Everything is stable and far from the “bleeding edge.” There’s support and copious documentation online for our entire stack and we don’t have any code locked into abandoned frameworks or languages. We play with the coolest, newest tech in our personal side projects.

First things first vs Theory of Constraints

If you’re following the Theory of Constraints, you find your system constraint and you work to optimize it. Drucker has a slightly different–yet compatible–objective in the bulk of this chapter. He wants us to explicitly cull activities that draw resources away from what’s important. And one way you can figure out what’s important is to follow Drucker’s four steps to identifying priorities. But you could just as easily substitute the Theory of Constraints here and you’d still be on solid ground. The Theory of Constraints doesn’t really say anything about culling projects to make room for new priorities. And, in that way, they dovetail nicely.

Wrapping up

You’ll discover your maximum effectiveness when you commit to doing the most important thing first. And then when that’s done, you should review the situation and pick the new most important thing to do and concentrate all your energy on that. To free up your time and resources, you must ruthlessly cull anything that is no longer productive.

What you should know about the Effective Executive: part 3

This post is part of a series on The Effective Executive (by Peter F. Drucker). You can find the first post here. In this post I’m going to tackle chapter 4: making strength productive?

Chapter 4: making strength productive

Most people have one or maybe two strengths if they are lucky and a great many weaknesses. It is the most important job of an organization to find the strengths of their employees and minimize or render irrelevant each person’s weaknesses.

Why improving weaknesses doesn’t work

Trying to improve weaknesses is a losing strategy. With great effort you might be able to achieve mediocre performance in an area of weakness. In most cases, it’s a waste of time and energy to work on your weaknesses.

For example, Michael Jordan was one of the greatest basketball players of all time but his performance as a baseball player was barely noteworthy. He did it because he wanted to do something different but his contribution to his team was undoubtedly higher when he was playing basketball. If you owned both a baseball team and a basketball team and Jordan worked for you, which sport would you insist he play?

Building on strength is the way to go

It’s much better to find out what a person does best and nurture that talent. Can you imagine where Michael Phelps would be today if someone had said you’re really good a swimming but I noticed your a crap gymnast. From now on you’re going to split your time evenly between swimming and gymnastics. How do you think that would work out?

Yet, as programmers, we encounter that kind of thing all the time. Bob’s a pretty good programmer but he’s not very good at public speaking. He’ll have to work on that. Or Jill’s a great programmer but she doesn’t have strong leadership qualities. She’s going to have to work on that. What do either of those things have to do with being a great programmer? Drucker would make sure Bob didn’t have to do any public speaking and Jill wasn’t put in leadership positions. It’s a simple solution. These people have spent years or decades honing their skills as programmers–and it’s a really difficult field–so why would we want these people to devote their time and energy struggling to become adequate in a skill that isn’t important to their success as programmers?

It’s kind of like Fight Club, if I can paraphrase Tyler here, “If he’s good at back-end programming tell him he’s no good at front-end programming. If he’s good at databases tell him he sucks at embedded. If rocks at embedded tell him he sucks at OS programming.” It’s some kind of messed up cultural thing where we torture good, hard working people by pointing out their weaknesses and make them feel bad about them.

Hiring

If you are ever asked to help with hiring, I strongly recommend you read this chapter. It’s full of advice on how to hire for strength and why that matters. I’m not going to dive into hiring here but just know that chapter 4 of The Effective Executive has been helpful to me when I’ve been involved in hiring.

How do I manage my boss?

Allow me to quote Drucker:

Above all, the effective executive tries to make fully productive the strengths of his own superior.

What does that mean? It means that you should actively try to help your boss succeed by playing to his strengths.

More from Drucker:

The effective executive therefore asks: “What can my boss do really well?” “What has he done really well?” “What does he need to know to use his strength?” “What does he need to get from me to perform?”

Of course this makes perfect sense when you think about it. There are many paths to success in business. A boss with an engineering background will likely have completely different strengths than an MBA or someone coming from sales. Your effectiveness, the effectiveness of your boss, and the effectiveness of your company depend in part on you figuring out what your boss needs to maximize his strengths and helping him get it. It’s not terribly difficult to figure all this stuff out; you just have to pay attention and experiment a little.

Finding your talents

Many people, and especially young people, have only the vaguest idea of their talents. If you try enough things in life you’re eventually figure out that you’re better at x than y. But that’s a really a slow and expensive way to find your talents.

Drucker doesn’t have much to say on the topic other than that it’s important. So I recommend you read StrengthFinder 2.0 (Tom Rath). Each copy of this book has a one-time use access code (note: some people are saying that the kindle versions don’t have the code so maybe stick with the physical book) to take a rapid-fire 177 question test and it splits out your top five talents. Then you can use the book to help you interpret and understand the results.

Millions of people have taken this test and the consensus is that it’s a valuable tool for discovering your talents. My wife and I both did the test and we thought the results were bang-on. Even though we couldn’t put our strengths into nice categories before we read the book, we totally agreed with our results.

Once your find your talents it takes practice and dedication to turn your talent into a strength.

So read the book and do the test. Discover your talents and work to improve your skills in those areas to bring out your strengths. And, as a side benefit, you may start to see other people’s strengths and adjust your interactions with them accordingly.

Conclusion

Drucker is absolutely correct to focus us on strength as opposed to weakness. We have a cultural fixation with weakness and it’s not helpful or healthy. Find the strengths in yourself, your boss, and your co-workers. Do what you can to play to those strengths and minimize the weaknesses. It’s a 10x programmer thing to do.

What you should know about the Effective Executive: part 2

This post is part of a series on The Effective Executive (by Peter F. Drucker). You can find the first post here. In this post I’m going to tackle chapter 3: what can I contribute?

Chapter 3: what can I contribute?

Drucker summed up “what can I contribute?” nicely when he wrote:

The focus on contribution turns the executive’s attention away from his own specialty, his own narrow skills, his own department, and toward the performance of the whole. It turns his attention to the outside, the only place where there are results.

No one hires a computer programmer to write code. Just as no customer is going to accept a 10% increase in the price of a product because it contains 10% more code than last year. People hire programmers to help solve problems and exploit opportunities that are important to them and their customers. They want our results, not lines of code.

It’s your job as a 10x programmer to find out how use can apply your unique skills to make the greatest possible contribution to your company. That was the thesis of my post: How to be a 10x programmer.

Many people would classify all this as obvious. But I can assure you that it’s not obvious to everyone. I can say this with 100% certainty because at one point it wasn’t obvious to me.

How I wasted a week building a feature that no one ever used as intended

Many years ago my boss approached me to build a new feature for our ERP system. He wanted functionality to keep track of a resource that wasn’t tracked in the system. He had it mostly planned out before he came to me and basically said, “build this.”

It was a basic CRUD feature that also tied into a few other existing reports. The form contained 38 fields and had three separate search forms. I thought that many fields was problematic from a usability point of view but he assured me he needed every field. The new reports based on this information just dumped data onto the page. They weren’t searchable, couldn’t be sorted, and they had no filters.

I asked a few questions about the purpose of the feature and how he wanted it implemented. Then, like a good little employee, I dove into the task and a week or so later, I finished it.

The results

The results were underwhelming. Our users never used the form as my boss intended. They entered the minimum information to accomplish their goals, including entering “dummy” information to get around required fields. After several years in production, there were still several fields that no one had ever used. The reports weren’t very useful either. The best users could do was use their browser’s “find” feature to search for text in the report.

What went wrong?

You can probably dissect this project ten different ways but the part I’d like to focus on is that I didn’t have a ‘what can I contribute?’ mindset. My boss gave me a task and I blindly followed his instructions. And, in so doing, I failed my boss and the users of our system. My boss didn’t know anything about building software, user interface best practices, or requirements elicitation. We can’t blame him for not knowing that stuff, that’s why he hired me.

Yet, either one of us could have rescued this project. He could have saved the project by stating the problem he wanted solved and then asking me to figure out how to achieve the best result. And I could have saved the project by asking ‘what can I contribute?’ and realizing that it’s not my job blindly build whatever my boss tells me to build. My job is to figure out what needs to be done and deliver results.

Lessons learned

Looking back on it now, I can see that I wasn’t confident and aware enough to challenge my boss and ensure I built something useful for our customers. I was too focused on pleasing my boss and not focused enough on the users of our system.

These days I’m more assertive. If someone presents me with a solution they want me to implement, I tactfully take a step back and ask how they came up with this solution or why this solution instead of some other solution. Then we usually have a discussion about the actual requirements and perhaps ways we can change the solution to be more useful to the users or easier to implement or whatever. I’ve trained my co-workers and bosses to expect that asking me to build something is going to result in a ton of questions. It’s scary at first but I haven’t been fired yet.

Conclusion

I love that line from Fight Club: “You decide your own level of involvement.” Most positions are defined to be these small, constrained things: Sally is the database person, Julie does front-end development, Bobbi does android apps, and so on. And you can have a whole career within one of those labels if that’s what you want. If you competently do what you’re told and stay in your lane, you’ll get good or even great review but there’s so much more to be had. 10x programmers have the opportunity to make their job as big as they want by delivering outstanding results again and again. It all starts by asking, “what can I contribute?”

So, what can you contribute? Are you just a code monkey that converts requirements into executable instructions for a computer or are you something more? How can you best apply your unique skills and talents to delivery outstanding results for your organization? What do you have to learn to make an even bigger contribution?

What you should know about the Effective Executive: part 1

The Effective Executive by Peter F. Drucker is one of my favorite business books of all time. It should be on every 10x programmer’s reading list for two reasons. First, it offers knowledge workers (including computer programmers) a guide to becoming ridiculously effective. Secondly, many millions of business people have read this very influential book and by reading it, you will gain insight into how many business people set priorities and approach their work.

No matter how good of a programmer you are, I promise you that you can get better by reading this book and applying its lessons.

The Thesis of the Effective Executive

Drucker’s thesis is that effective executives have many different styles but they share several characteristics. They:

  • ask “What needs to be done?”
  • ask “What is right for the enterprise?”
  • develop action plans
  • take responsibility for decisions
  • take responsibility for communicating with the people around them
  • are focused on opportunities rather than problems
  • run productive meetings
  • think and say “we” rather than “I”

If I can quote from the book for a moment: “The first two practices gave them the knowledge they needed.  The next four helped them convert this knowledge into effective action. The last two ensured that the whole organization felt responsible and accountable.”

If that sounds promising, keep reading. I’m going to write about one or two things from each chapter of the Effective Executive that I find particularly applicable or interesting in regards to programming. It’s a big topic so I’m going to tackle one our two chapters per post and turn this into a series.

Chapter 1: effectiveness can be learned

Drucker argues (and I agree with him), that effectiveness is the result of making a habit out of a series of practices that influence effectiveness. Your intelligence is relatively fixed and you probably didn’t get to pick your co-workers or your boss but you can practice the habits of effectiveness. These habits include:

  1. knowing where your time goes
  2. focus on results your customers care about
  3. build on strengths (your own, your co-worker’s, your boss’s, your company’s)
  4. focus on a few major areas where superior performance will produce outstanding results
  5. making effective decisions

So wherever you are on the effectiveness spectrum, you can always improve.

Chapter 2: know thy time

Everyone gets the same 24 hours each day. You get to decide how you use them. Drucker argues that effective knowledge workers find our where their time goes, cut everything that’s not productive, and consolidate time into large blocks where real work can be done. If you don’t manage your time, you’ll be swamped by ever increasing demands on your attention and interruptions. And you won’t accomplish much of anything.

I’ve done quite a bit of work in this area.

Time tracking at work

We use Jira to manage our stories and we record our time in Toggl. I track every minute of my day to a task in Jira, specific meeting, or phone call. Every two weeks we run a script to analyze where we spent our time. Then during our retrospective meeting we investigate anything that’s suspicious and do what we can to eliminate time wasters.

Meetings

Meetings are always a huge danger area. I’ve tried various strategies to keep things on track. When it’s my meeting, it’s pretty easy to keep things progressing. But if I’m in someone else’s meeting it’s a little more difficult to create a sense of urgency without taking over.

The best way I’ve found to create a sense of urgency is to have a prioritized list of things we are trying to accomplish and talk about it all the time, both in and out of meetings. During meetings I say stuff like, “Let’s get through this meeting quickly so we can get back working on [our highest priority task]”. If we stray to a topic that’s not on the list or is on the list but we won’t get to it for a while, it’s easy for me to say, “Let’s defer this discussion until it get closer to the top of the list.” It works.

My wife is invited to attend lots of meetings with her work. They got so out of control that she now refuses to attend any meetings without a written agenda distributed in advance. Smart.

Working from home – the ultimate productivity hack

By working from home I’m able to avoid a lot of the interruptions that eat into most people’s days. I attend scheduled meetings and daily stand-ups by Skype and generally have two large uninterrupted blocks of time each day. People mostly communicate with me asynchronously (email, Jira, BitBucket, etc.). I also avoid commuting, which saves me 40 minutes per day over the average person. Here’s a Ted talk with some research results on the benefits of working from home: https://youtu.be/oiUyyZPIHyY.

If you think working from home might help you be more productive, you might suggest it to your boss as an experiment where you just try it for one or two days a week and see how it goes.

Email

Ugggghhh. I struggle with this one. The habit I’m trying to form is to reply by phone if that would be faster than writing an email. My time tracking showed that, like most people, I spent a lot of time on email. I’d write these detailed responses and re-read them and edit them to make them complete and correct. And before I knew it I wrote a little essay and 45 minutes of my life were gone. On the other hand, I use writing as a way of thinking. By writing something down I really get to know what I think about it. I’m getting better but I still catch myself writing when I should pick up the phone.

Avoiding interruptions

If too many people are popping by your office and making you lose your flow, I have two things you can try. First, lots of people wear ear phones as a signal to others not to disturb them. They also help block ambient noise, which helps me focus.

The other thing I recommend is a stoplight system. Tape a folder to your door and place a red, yellow, and green sheet of paper in the folder. Cut the folder so the paper is visible. Set it to red when you are doing something critical and you don’t want to be interrupted unless it’s an emergency. Set it to yellow if you are working on things that require concentration but aren’t so important that an interruption will cost you a bunch of time. When it’s yellow, your coworkers are invited to stop by to talk about work concerns but not to visit. And set it go green when people are welcome to visit (socializing is an important part of being on a team). Green might be good for times when you are answering emails or doing research.

It’s pretty easy to sell the stop light system to people. Just say that you’re running an experiment to see if you can increase your productivity and that you’d appreciate your co-workers’ cooperation. If your experiment is successful, you can make it permanent.

Automate things

Because we are computer programmers, we can automate things. And we should automate things if we’re sure they will payback in a reasonable amount of time.

In my experience we don’t think through these little automation projects to the same level as “official” Jira tasks. And that leads us to make optimistic estimates of how long they will take and the benefits we’ll get from any particular automation project. XKCD has two excellent comics related to this: one is on automation and the other is on the payback from making tasks more efficient. If you carefully choose things to automate, you’ll be okay. If you automate blindly, you’ll waste a bunch of time.

Never let up

You must make time management one of your ongoing concerns. The moment you stop paying attention to where your time goes waste will start creeping into your calendar and your effectiveness will suffer.

Conclusion

I once read that the average computer programmer writes about two million lines of code over the course of his career. Someone picked that number out of their ass but it really stuck with me anyway. Whenever I encounter something stupid or when someone suggests a feature that doesn’t really matter to our customers or our company I think about how this is going to burn x lines of code from my finite limit. And that motivates me to fight to not waste time writing code that doesn’t matter.

If you really want to light a fire under your ass about how finite your time is, check out Your Life Visualized in Weeks. Your career will go by in the blink of an eye–don’t waste a second.

How to calculate contribution margin for fun and profit

In my last post I gave you a brief introduction to managerial accounting, showed you how to calculate contribution margin per unit, and told you why it is important. In this post I’m going to show you how I calculated our contribution margin per unit for every product we sell and how we used that analysis to change the course of our company.

Our question

We had several questions related to profitability. But, for this post, our goal is to figure out how to calculate contribution margin per unit for our online tree business and have a look at what that tells us.

How to calculate contribution margin: what costs go where?

The most difficult part of this whole project was taking a bunch of receipts and making decisions about how costs should be assigned to each tree so that the contribution margin we calculated would be valid.

For example, let’s say we paid $1,000 to ship a load of trees from our nursery to our cold storage facility. This cost is clearly an avoidable and incremental cost (if we shipped zero trees, the cost of shipping would be zero). Therefore, this cost must be included in our contribution margin calculation.

The question is how much of that $1,000 cost should be assigned to any particular tree? My first thought was to take $1,000 divided by the number of trees in the load but that didn’t seem right. Some trees are so small that you can fit five of them in your hand but there are also four foot tall trees. Surely the cost of shipping the smallest and the largest trees shouldn’t be the same.

I tried a couple of ideas and the one that worked best was to calculate how many of each kind of tree would fit in all the boxes we would theoretically put on a pallet. So for the smallest trees we might be able to fit 8,100 trees per pallet. And only 400 trees per pallet for the largest trees. Then I calculated how many pallets fit in the trailer and used that number to figure out the shipping cost per pallet. Then I used shipping cost per pallet to figure out the shipping cost per tree. Does that make sense? Big trees cost more to ship than small trees, right?

Anyway, I went through the process of trying to fairly allocate all the incremental and avoidable costs for each tree and for each order.

Some things were easy. Like credit card transaction processing fees. And some things were difficult such as calculating how much it cost us to pick and pack each order in our warehouse.

How I did the actual calculations

I used the pandas data analysis python library to do all the math. Pandas is amazing for this kind of work. I started with a bunch of CSV files that I either hand made in a spreadsheet or that I dumped directly from our database. I imported those CSVs in pandas, did the necessary data transformations and joins to get the data into the correct shape, did my calculations, and exported the results as CSVs. From there I sorted, filtered, pivoted, and graphed the output in a spreadsheet to my heart’s content.

As an aside, it would be torture to try and do all these calculations in a spreadsheet. I ran the pandas scripts hundreds of times as I tweaked the calculations to increase their accuracy. This is the part of this project that only a programmer could do.

I used pandas to calculate the contribution margin for each order and for each product in that order.

Once I got that data into my spreadsheet, I could answer any number of questions about contribution margin. For example, what is the contribution margin by:

  • species
  • age
  • age and species
  • customer segment
  • province
  • customer

What did we find?

We were surprised by many of the results. We were all operating on a set of shared assumptions about how our business functioned and where we made our profit. But without any prior analysis, we were wrong as often as we were right.

Let’s look at two examples of the surprises.

Older trees are more profitable than younger trees

At the time, we were selling 1-4 year old trees. And the consensus was that older trees were more profitable than younger trees. White spruce was priced something like this:

  • 1 year old – $1.99
  • 2 year old – $3.99
  • 3 year old – $6.99
  • 4 year old – $9.99

$9.99 is clearly better than $1.99 so we intentionally grew the older trees and promoted them aggressively. Boy, were we wrong. The contribution margin for 1 and 2 year old white spruce was healthy and almost equal. Three year olds were about break-even and we lost about $15 on every 4 year old white spruce we sold!

Here’s what happened. We grow one year olds in a greenhouse and we pay a fixed price for each tree. Then we ship them to our cold storage warehouse for the winter. Then we ship them back to the nursery in the spring where the plant them outside. The trees that survive the summer are harvested in the fall and the cycle repeats. But ever time you harvest the trees you lose some, and the older the trees, the bigger the loss. It goes something like this:

  • 1 -> 2 year old = 90% survival
  • 2 -> 3 year old = 65% survival
  • 3 -> 4 year old = 50% survival

So if you start with 1,000 one year old trees, you end up with 900 two year olds. Then you transplant them and end up with 585 three year olds. And then you transplant them and end up with a pathetic 292 four year olds.

So we have 292 four year old white spruce to sell at $9.99 each. But what did it cost us to produce those 292 trees? Well, we need to assign the cost of all the lost trees among the way to the 292 trees that survived, plus all the shipping, storage, growing, handling, and other fees all along the way (including the trees that died). When I added all those numbers together we were losing $15/tree!

But it was even worse than that. We give our customers a guarantee that our trees will put on new growth in the first summer or we’ll replace them for free. Four year old white spruce had a survival rate well below 50%. So when you take our guarantee into account, we lost even more money on four year old white spruce.

The math both surprised and shocked us. The forcing function on the cost of older trees is the recover rate (which no one had realized). The recovery rate varies from year to year and species to species. But after I did some additional calculations, I determined that we had lost money on every four year old tree we’d ever sold! And we hovered around break-even on our three year old stock.

We discontinued our four year old stock and severely curtailed our three year old stock to species we could sell profitably (now that we had hard numbers to guide us).

Fruit and berries are our future

We thought that fruits and berries were a significant source of contribution margin for us because they were high priced and we felt like we spent a lot of time talking to customers about them. But the contribution margin from fruits and berries was a few percent of our total contribution margin. Even though we spent lots of time on the phone helping customers buy them, the volume wasn’t that great. And our total cost on fruits and berries was much higher than our average trees.

We saw fruits and berries as the future of our business but our contribution margin analysis showed that they weren’t our core business. It further showed that we would have trouble turning fruits and berries into a core business; doubling fruit and berry sales would barely move the needle. We scrapped that plan pretty quickly.

Other discoveries

  • our volume discounts were too generous. When we gave customers our largest volume discount we found many of those orders had large negative contribution margins
  • there were huge differences in contribution margin ratios for different species even though they might sell for similar prices
  • we assumed that small orders had low profitability but we our analysis showed that small orders were quite profitable as a group

Our takeaways

Our assumptions about how our business made money were shockingly inaccurate. It wasn’t that our people didn’t care or weren’t smart, it’s just impossible to take all the important factors into account and do all that math in your head. With only a few weeks of my time, we were able to replace our assumption and intuition-based management style with a data-driven management style.

We made many changes to our business based on our contribution margin analysis and our profit soared as a result. Having contribution margin data also allowed us to make other changes that I’ll describe in my next post.

Takeaways for a 10x programmer

This is the perfect kind of project for a 10x programmer. It’s unlikely any non-programmer is going to decide to learn python and pandas and learn how to calculate contribution margin on his or her own. Yet, without some kind of scripted analysis or software that can do the heavy lifting for you, these calculations are all but impossible. By crossing over into another functional area for just a few weeks, you might be able to change the course of your company. Can you think of an activity you could do with a higher return on investment?

If your company isn’t doing a contribution margin analysis, you might want to consider doing one. Don’t be intimidated by the scale of the challenge. Don’t let the difficulties associated with assigning costs stop you. Find someone to work on it with you and just go for it. And don’t worry if your analysis isn’t perfect–they never are. Do as well as you can with the time and data you have available. Just be honest with people about the limitations of your methods. It’s not a big deal as long as people understand the limitations of your analysis and use the data appropriately.

Further reading

The Strategy and Tactics of Pricing: a Guide to Profitable Decision Making (Thomas T. Nagle and Reed K. Holden) is THE book to read on the topic of pricing. Get your boss to buy you the most recent edition of the book. Read it first and then get your boss to read it. Neither of you will regret it. The authors explain the hows and whys of everything I did here better than I can. And they cover so much more than how to calculate contribution margin. The whole book is excellent.

Wrapping up

I hope I’ve convinced you of the power of contribution margin analysis and the important role you can play in your company. You just have to shift your mindset and view your whole company as fair game for optimization.

How to calculate contribution margin per unit

I want to tell you the story of one of the biggest impacts I ever made. I’m going to assume that you don’t know much managerial accounting. That’s fine; I didn’t either when I started this project. I’m going to give you a five minute tutorial on managerial accounting in this post. Your goal is to understand how to calculate contribution margin per unit and why it’s important. Then I’ll get to my story.

Our problem

Our company sells tree, shrub, and berry seedlings online. Before we did any managerial accounting we carried a few hundred different species and ages of trees. We knew that we made a profit overall at the end of the year because our financial accounting showed a profit for the whole business. But we had only a fuzzy idea how much profit we were making on each product individually.

We were largely in the dark on many important details such as:

  • how profitable are our products?
  • which products are the most profitable? least profitable?
  • are we selling any products at a loss?
  • which customers are most profitable? least profitable?
  • which segments of our market are the most profitable? least profitable?
  • are our products priced correctly? what would happen if we raised the price 20% or lowered it by 10%?
  • if we find ourselves overstocked what price change should we make to generate the most profit?
  • if we only have room to grow another 10,000 trees, which species and ages should we grow to maximize profit?
  • how can we increase the profitability of our business?

I did some research and found out that managerial accounting had the answers to all our questions (or at least a method to help us figure it out).

Why should a programmer like you care about managerial accounting?

Managerial accounting can help managers make smart decisions about the direction of their company. But in our company–and I suspect many companies–we didn’t have any way to do any managerial accounting calculations. All our detailed sales data was in our web database but all our receipts and accounting data was stored in a completely separate system. The business people understood the power of managerial accounting but lacked the computer skills to do the actual calculations.

And that’s where 10x programmers come in. They see the value of the calculations and jump at the chance to learn how to slice and dice the data and do the calculations required to calculate contribution margin.

If your company isn’t doing any kind of managerial accounting, introducing it could be a game changer–it sure was for us. Plus, I’m only giving you the tiniest introduction to the potential of managerial accounting. It’s a huge area with many excellent ideas for an aspiring 10x programmer.

Let’s get some definitions and calculations out of the way and then I’ll continue my story.

What is managerial accounting

Managerial accounting is a system of accounting used to help managers make better decisions within their organizations. This is a separate discipline with different goals than financial accounting (with its famous income statements and balance sheets).

What is contribution margin

Contribution margin is the selling price per unit minus the variable cost per unit. “Contribution” represents the portion of sales revenue that is not consumed by variable costs and so contributes to the coverage of fixed costs.

How to calculate contribution margin

Contribution Margin is the money left over from sales after you subtract your variable costs

Contribution Margin is the money left over from sales after you subtract your variable costs.

The easiest way to understand contribution margin is with a simple example. Suppose you had a lemonade stand and you sold 1,000 glasses of lemonade at $1/glass. The lemonade cost you $200 and your glasses cost $100.

Contribution margin = selling price – the sum of all incremental and avoidable costs (in this simplified case they are your lemonade and glasses).

$700 = ($1 x 1,000) – ($200 + 100)

Once you have your contribution margin, it’s easy to calculate your overall profit if you know your unavoidable and sunk costs (in this simplified case these are your fixed costs).

Fixed costs:

  • lemonade stand: $200
  • advertising: $100
  • sunscreen: $25

Fixed costs = $325

Profit = contribution margin – fixed costs

$375 = $700 – $325

How to calculate contribution margin per unit

Break-even point for contribution margin

Break-even point for contribution margin

Contribution margin per unit = Contribution margin / number of units sold

$0.70 = $700 / 1,000

Each glass of lemonade you sell adds $0.70 to our contribution margin. The contribution margin on your first glasses of lemonade is used to cover our fixed costs.

At some point you reach your break-even point, after which all the contribution margin you make is profit. I’ll leave it to you to calculate the break-even point on your lemonade stand.

Why does contribution margin per unit matter?

Once you calculate contribution margin per unit, you can easily compute:

  • your break-even point for each product (the number of sales required to cover all fixed costs)
  • projected profit for a given sales forecast
  • which of your products are most profitable (if you calculate the contribution margin per unit for all the products you sell individually)
  • the relationship between changes in selling price and profit (how many more units you have to sell to break even on a price drop or how many fewer units you need to sell to break even on a price increase)

You can use this information to make informed decisions about your product mix, marketing strategy, and pricing strategy. This information gives you an advantage over competitors making these decisions based on historical data and guess work.

Conclusion

Thanks for hanging in there. I know this post was a little dry. But I promise it was both necessary and worth the effort to give you the background required to appreciate the story of one of the biggest impacts I ever made. Stay tuned.

How a Google experiment saved my ass

Let me tell you about the time a Google experiment saved my ass.

For those of you who don’t know, Google Analytics has an A/B testing feature. You can create multiple variants of a web page and then setup an experiment where Google Analytics directs your traffic to the different versions of your page. Google records how your visitors respond to the difference on some dimension that’s important to you like signups for your email list or purchases from your website. Google takes care of all the mechanics and statistics and tells you the winning variant or that it was too close to call.

Anyway, back to the story.

My goal

I am responsible for an ecommerce site and we thought it would help our conversion rates if we displayed some testimonials next to our products. Most of our customers are first-timers and we thought that testimonials would be a great addition to the site.

Implementation

We didn’t have any testimonials so I painstakingly contacted customers who reported high satisfaction with our products in a recent survey and asked them if I could use some of their comments on our website and promotional materials.  I collected 94 excellent testimonials in all. It took days.

I put them in a database table and we found a blank area on the site where the testimonials would fit. And then I designed and implemented a feature to call five random testimonials from the database and render them on the product page. Each product page would get a different five testimonials and they were cached for 24 hours and then another five random testimonials would be generated for each product. I thought it was pretty slick.

The Google experiment

I’m not really a front-end guy so I rely on Google experiments to test major changes to our site. I’ve been surprised over and over again with how many ‘good ideas’ end up hurting our conversion rates.

So I setup a Google experiment for the testimonials feature.

Results of our Google experiment

The version with the testimonials converted 47% worse than the original. Ouch!

Here’s a screen capture:

Google experiment results graph

So that wasn’t even close. Clearly my instincts for conversion rate optimization are terrible.

What did I learn?

Well, the obvious thing was that the testimonials didn’t work as we implemented them.

I also wasted a ton of time collecting and organizing all those testimonials. I conducted the Google experiment as an afterthought to prove that the testimonials were better than the original version of the site. But I never considered the possibility that they wouldn’t work. If I was going to try this again with the benefit of hindsight, I would probably just collect a handful of testimonials and hack them into the site for the Google experiment. Then if that experiment worked, I’d go back and collect more testimonials and improve the code to use the database and caching.

I think the bigger lesson is that feedback is extremely valuable. The Google experiment maybe took me two hours and it told me that I was about to tank our conversion rate.

Let’s think about what would have happened if I hadn’t run the experiment and just launched the feature. We probably would have noticed sales were off in a couple of days. But then what would we do? Probably sit on it for a few more days to see if the conversion rate bounced back. And then we might have speculated about the effect of weather or maybe our search rankings dropped or our Adwords weren’t working as well any more. There are so many things changing in our business that I don’t know if we would have ever have suspected the testimonials were killing us.

I speak from experience

I wanted to run the experiment on the testimonials because I had been surprised by a website changes in the past.

The big redesign

Several years back we decided to completely redesign our ecommerce site. It looked dated and lacked features we thought were important. So we hired a graphic designer. She and I worked on the design with feedback from other employees and I implemented the a new version of our whole site from scratch. The whole thing cost a small fortune in time and treasure. And the impact on conversion rates was…basically zero, according to Google Analytics.

I just couldn’t believe it. I studied the stats trying to find a way to explain why they were invalid or misleading but after a couple of hours I had to admit that there was no evidence that the new site converted any better than the old site. Many of my co-workers disagreed with that assessment but no one could find fault with the math so we all stopped talking about it.

Enlightenment

I was so confused by this result that I found a couple of books on conversion optimization and read them cover to cover. And it didn’t take long for me to realize how little we knew about building websites. We had the mechanics down but we didn’t understand conversion optimization at all.

So I evaluated our site with my new knowledge and a bunch of things on our site looked like the examples of what not to do in the books. One thing in particular caught my attention. We had this giant banner on the home page advertising one product that we thought our customers really loved. On the screen sizes popular at the time, the header and this banner took up the entire first screen of the home page. I tried to explain how the banner was an example of what not to do but people loved the banner–they were proud of it–and I couldn’t get permission to remove it.

My first Google experiment

I had read about Google experiments in those conversion optimization books and I convinced my boss to give it a try on the banner. We ran the experiment and removing that banner and one other item from the page boosted our conversion rate 72%! Can you believe that? I was sold on A/B testing from that day on.

What’s the bigger lesson here?

Aside from my plug for Google experiments and A/B testing changes to your website, I think the bigger lesson is that working with feedback is super important. How many things are we doing in our jobs that aren’t contributing to our success? If we aren’t checking if our changes or initiatives are working better than what we did before, how do we know they are better? We need feedback.

Since I started testing, I’ve found quite a few things that aren’t worth doing. For example, we used to produce a paper price list/catalog and mail it to customers. It cost a small fortune every year. But one year we randomly selected a number of names from the database and didn’t send them the price list and then tracked the sales through the year. The result: no difference. Again, people questioned the result. It just seemed impossible that it didn’t help, even a little. But in the end, we couldn’t escape the math and we scrapped the price list and never looked back.

How many things are you doing at your company that might be exactly like our price list–a complete waste of time and money? Could any of those things be effecting your constraint? Can you think of a way to test whether they perform as people suspect?

Wrapping up

Google makes it easy to see if version A or version B of a web page performs the best. And that’s good and you should definitely do those kinds of experiments where the outcome matters. The bigger takeaway is that A/B testing can help you solve really big problems for your company. I guarantee you won’t regret adopting a testing mindset.

How to be a wildly successful small business programmer


This is my final post in this series on how to be a wildly successful small business programmer. We’re going to do a quick review of everything I’ve talked about in this series. And then I’ll leave you with some parting words to help you continue your journey and show you where we’re going next.

A summary of how to be a wildly successful small business programmer:

What’s so different about being a small business programmer?

I defined small business programming and enumerated the challenges and the opportunities of working as a small business programmer.

Are you ready for a change?

I encouraged you to make sure your job is secure and that you are ready to learn how to be a wildly successful small business programmer.

How to be a 10x programmer

I argued that 10x programmers have a different mindset than regular programmers. 10x programmers view their whole company as fair game for optimization. They dare to look outside their assigned role to understand the bigger picture. They find the place where their effort will have the most effect and focus on maximizing the value of their contribution to their company.

Theory of Constraints for 10x programmers

The Theory of Constraints is a powerful tool in the hands of a 10x programmer. It allows you to quickly focus in on the part of your company that is holding everything back and helps you figure out what you need to change to make things better.

Increase your effectiveness

I showed you how to use the Theory of Constraints on yourself to increase your effectiveness by working through an example.

Where to look for the constraint in your company

The best way to find the constraint in your company is to figure out how it really works and then use a current reality tree to find your constraint. The second best way to find your constraint is the use the 5 whys problem solving technique.

Pretend that your company is a computer program and you’re just poking around trying to figure out how it works and where the performance problems reside, if that helps put it in familiar terms.

The point is to get you thinking about your company as a system and look for the constraint. You need to get familiar with parts of your company not related to programming. And start to see the bigger picture.

Let’s talk about change

As a 10x programmer, you need to know how to change yourself and how to help other change. We are drawn to radical change–also called innovation–because it’s dramatic and we intuitively think that’s the best way to change. But continuous improvement wins almost every time.

Building your influence in six steps

Your goal is to become a trusted source of ideas and information for the decision makers in your company. You want them to seek your opinions and ask for your help on their important decisions because you have a reputation for having great ideas. It is only from this position that you’ll have the influence to work on your company’s constraint.

How to handle multiple possible constraints

Separating your actual constraint from multiple possible constraints is hard. This post helps you sort things out and chart a path forward when you are faced with multiple possible constraints.

How to choose your first project

Unless you are an owner or a senior manager, attacking your constraint directly is probably impossible. You’ll need an indirect approach where you can improve your skills, influence, and understanding of your constraint. This post presents you with the minimum requirements for your first project, some factors to consider, and some things to avoid when choosing your first project.

How to pitch your first project

If you tailor your pitch to your boss, really understand your idea, take responsibility for the outcome, practice, and execute well, you’ll have a good chance of getting your first project approved. This post should get you on the right track.

Your next steps to becoming a wildly successful small business programmer…

Hold onto your 10x programmer mindset and keep moving towards your constraint. These are the two most important things you can do.

Some people get discouraged when they hit their first ‘no’ or when they find their boss is unreceptive to their pitches. Fight the urge to dwell on everything you can’t do. Find something you can do and do it. You might find that your constraint is completely beyond your influence and no one will let you anywhere near it. That’s okay, just pivot to the place where you can have the next largest impact and focus your efforts there. People will notice your efforts–I guarantee it.

In one of my previous posts I introduced the idea that finding and overcoming your constraint is kind of like playing one of those quest games from the 1990s. You’ve got to explore, build your skills, gather tools, and talk to people if you ever hope to complete your quest. There isn’t a straight line from where you are now to overcoming your constraint. You need to be persistent.

Specific things you can do

What’s next for this blog

Now that we’ve got the basics of how to be a wildly successful small business programmer out of the way, I’m going to start filling in the details and posting information on specific skills and techniques for aspiring 10x small business programmers.

Here are some broad categories of things I’m planning to write about:

  • case studies
  • programming skills
  • business skills
  • soft skills
  • mindset

Stay tuned.

How to pitch your first project

Today I’m going to show you how to pitch your first project. This is my follow-up post to how to choose your first project.

Let’s jump right in.

Preparing to pitch your first project

In an ideal world, everyone would see the brilliance of your ideas and you wouldn’t need to convince anyone, including your boss, to act on them. But you know things are a little more complicated in real life. And a little preparation can be helpful.

Tailor your pitch to your boss

Your first step is to tailor your pitch so that your boss will see it in the best possible light. Driving Technical Change (Terrence Ryan) is a great guide for figuring out what kind of person you’re dealing with and how to win them over to your way of thinking. It’s not foolproof but this book can help you avoid making silly mistakes when you are trying convince your boss green light your first project.

Is your boss more likely to say yes to a high-level verbal summary of your idea? Or does she want all the details written out? Or something in between? Does she like PowerPoint or think it’s the devil’s software? Does she make decisions based on reason and math or on gut feelings and intuition? Know your audience. Present the information in the way that’s easiest for them to consume, even if it might be harder for you to deliver.

Choosing your moment is important too. If your boss just had a stressful meeting, it might not be the best time to pitch. Or maybe your boss is checked out by the end of the day so mornings are best. Or maybe she’s sleepy after a plate full of carbs after lunch. Figure out when your boss would be most receptive to your ideas and set a meeting to pitch in the sweet spot.

Your boss is probably most receptive if she’s already talking/complaining about the problem your project will solve. If there’s a natural opening to pitch your idea, you might want to jump on it and make an informal pitch on the spot.

Really understand what you’re proposing

You need to really understand your project. What are it’s strengths and weaknesses? What’s the potential gain and likely cost? What kind of objections might your boss have and how would you answer them?

Is all this preparation overkill? It might be, depending on the situation. If you have a good relationship with an easygoing boss, you might just blurt out your idea as you pass her in the hall one day and she’s approve it on the spot. It’s definitely happened to me. But I’ve had pretty well thought out ideas shot down too. And once your idea’s been shot and killed, it’s pretty difficult to bring it back to life.

Take responsibility

Be prepared to take full responsibility for the consequences of your project. Imagine three outcomes: best case, probable case, and worst possible case. Can you live with the worst possible outcome? Will your company survive the worst possible outcome? Will your job? If you or your company can’t survive the worst case, you may need to rethink your plan. Is all this risk necessary?

Practice your pitch

When you’ve got your approach, facts, and arguments figured out, it’s time to practice your pitch. I recommend practicing your pitch with a trusted co-worker or a friend. Practice more if you’re anxious. Your goal is to come off as confident and competent, not negligent and nauseated.

Get feedback and use it to refine your ideas and your delivery. Both are important.

Pitch your first project

If you’ve followed all the steps in this post and the last, you should be well prepared to make a successful pitch. Follow your plan and deliver a pitch tailored to your boss’s preferences.

Dealing with a no

Your boss is going to say no sometimes, perhaps often. I have no idea how many times my ideas have crashed and burned but ‘often’ is probably a good description. It also varies from person to person. Some people are receptive to ideas and others are less receptive. My point is that ‘no’ happens and you should expect it.

Now here’s the key thing: find out why your boss said no and use the answer to come up with something better.

Here’s what you have to figure out:

  • is the problem with the idea or the presentation?
  • is it a timing issue? are there higher priorities right now?
  • is there a chance your boss didn’t understand the idea or the benefits? which parts were too hard to understand?
  • are there changes you could make that would turn this no into a yes? what are they?

Collect whatever feedback you can and incorporate what you learn it into your next pitch.

Wrapping up

So that’s my basic tutorial on pitching  your first project. If you tailor your pitch to your boss, really understand your idea, take responsibility for the outcome, practice, and execute well, you’ll have a good chance of getting your first project approved.

If you don’t succeed on your first attempt just pick yourself up and try again. Keep going until you succeed. You’ll get there.

In my next post I’m going to wrap up this series with a summary and some final tips on how to be a wildly successful small business programmer. Stay tuned.

« Older posts