If you lack a systemized process for setting and achieving goals, your likely to run into all sorts of problems:
Plenty of people will tell you the importance of setting goals. What people don’t tell you is how to choose, set and accomplish them.
In Measure What Matters, John Doerr lays out an approach to goals to tackle these challenges. John taught this to industry juggernauts Google, Intel, Adobe, and Intuit and others. Its design increases focus, commitment, and ambition. Among teams, It fosters alignment, transparency, and accountability.
The system is OKRs, short for Objectives and Key Results. An Objective is something that you intend to accomplish, your goal: Your what. An objective contains several key results, which are objective, quantifiable measures of progress: Your how.
Here’s an example OKR From their website:
the system works like this:
Before deciding your objective, you have to decide where it is you want to go. If objectives are what you are doing, and key objectives are how you are doing it, then where you are going is your mission.
For example, Google’s mission is to “Organize all the world’s information.” Your personal mission may be raising your children or gaining financial independence. Your company may have one of these plastered on a wall or ‘about’ page.
Choosing objectives you can commit to takes deep thinking. Don’t try to define objectives no Monday and begin working towards them on Tuesday. Give your self some time to consider exactly what it is you want to accomplish.
When you’re ready to move forward, lets take a closer look at how to define quality objectives and key results.
Objectives need to be clear and understandable. In the Healthcare.gov example you’ll see that while the objective sounds initially vague, the key results give it precision. You can set up systems to measure each of these and determine objectively how well you achieved your goal. Another benefit of clarity is that it increases alignment within a team. There’s no debate about what we are all working together to accomplish.
Achieving every key result achieves the objective. If that isn’t true then you need to tweak your OKR. One trick recommended in the book is to try to rewrite your objectives and key results ending with “as measured by ________”. In this case, your objective is measured by the sum of all key results.
Objectives must be worth achieving. What’s the point of pursuing a goal that isn’t going to have a significant impact on your business or life?
You should timebox objectives. The time frame could be monthly or quarterly, but its recommended to not think in longer time frames. Longer time frames mean aiming for more ill-defined objectives. Shorter time frames may be ok at the start, as a warm-up, but it is hard to accomplish significant work in a weekly time frame.
Write down your objectives. If you don’t, then they cannot be clearly discussed and people cannot be held accountable.
Key results must be measurable. As a general rule, they should be a number. “Deliver prototype by 10/31” is a number. On that date, the number of delivered prototypes will be zero or one.
These numbers should also be objective. Getting approval from a manager is not a good key result is all it relies on is one person’s discretion. If you want to set results for measures of quality such as user experience, find ways to quantifiably measure that, through either analytics or surveys.
Key results should include measures of quality. All metrics are games, and key results should be defined to prevent harmful gaming. For example, “publish 100 blog posts this quarter” is a dangerous metric, because it contains no bounds what a “blog post” is. A team ignoring quality could hit this target in weeks if not days. You could improve this KR by also defining a metric around the impact of the posts, such as conversion rates, engagement, etc.
Here’s where I think the system goes from solid to genius: When it comes to setting your goals, you should aim for a success rate of 70%. Aiming for a 100% goal rate gives you an incentive to set less ambitious goals. Have a hit rate too low means you are setting goals that are unachievable. 70% is a good middle ground: You succeed more than fail, but you are still stretching and being ambitious.
Imagine how different education would be if you were encouraged instead of punished for tackling challenges outside your comfort zone.
As a gut check, take stock of how you feel when you look at the OKRs you are responsible for achieving. How do you feel? Do you feel very confident that you pull them all off? Then you didn’t stretch enough. Can you shorten deadlines or increase targets?
What if you feel scared like there is no way you’ll even come close? That may be a sign that you are reaching too much. Setting goals that are unreachable are defeating. If you know you won’t come close, why should you try? What will motivate your team?
But, if you look at your targets, and you feel like maybe you could achieve these, or at least most of these, if you push yourself, then you’ve found the Goldilocks zone. You have objectives that will test you, but with a test that you can pass if you get outside your comfort zone.
As my coach likes to say: “Get comfortable being uncomfortable.”
While objectives completion is always a clear yes or no, measuring progress and achievement can be more nuanced. Let’s say in our previous example of writing 100 blog posts in a quarter. You could write 70. While you did not achieve the goal, you did achieve 70% of it. Think about measuring each of your key results on a 0.0 – 1.0 scale, with the following goal posts:
These numbers should be from both objective metrics and self-evaluation. Consider the 99% uptime key result from the earlier example. If your site has 70% uptime, would you say that’s yellow or red? In that scenario, a more reasonable scale would be something like < 95% uptime is red, 95-98% is yellow, and 98-99% is in the green range.
You may also consider separating objectives into “stretch” and “committed” categories. Some goals may be important to hit and you should really be thinking about going for 100% there. Others may be more ambitious but also less costly if they fail, so aiming higher there is ok.
Instead of annual or quarterly performance reviews, the OKR system encourages continuous feedback with another acronym: CFRs. CFRs stand for Conversation, Feedback, and Recognition. Conversations should focus on facts over feelings, and process over outcome. These are not a replacement for annual or quarterly performance reviews, which are used to determine other measures, mainly compensation based on performance. It’s important that you divorce feedback on goals from compensation. Changing compensation is backward facing and about the person, while CFR discussions are forward facing and about the goal. Both are more effective when decoupled. Here are 5 questions from Measure What Matters that can help frame these discussions:
As teams work together, it’s important to remember to recognize when others do well in a public and visible manner. It helps people remember how their work helps others.
OKRs are primarily designed for teams, although I think they are valuable for individuals also. When working in teams, how multiple OKRs interact with one another is another powerful part of the system.
OKRs cannot be written and handed down from up high. You must write them collaboratively. However, One manager’s Key Result and be someone else’s objective. For example, let’s look at the Healthcare.gov example again. Let’s imagine that this OKR is from the CTO who is responsible for the project. One of the key results is 99% uptime. This could be an objective for the person or team who is in charge of systems administration, who could then define sub-KRs that could them achieve that objective. You can break the KR “Response time of under 1 second” into other objectives and key results for front end and back end development teams. While OKRs are not assigned top-down, they do cascade down or sideways. This helps people contributing at any level to see how their work connects to the bigger picture.
A single person should own objectives. If that’s not possible then they should be owned by a single team. Focus is important, so no single person or team should have more than five objectives. Another benefit is the focus that this brings. If work does not go towards or at least facilitate the pursuit of a key result, then you can confidently remove it from the backlog of tasks.
The interconnectedness leads to another feature of OKRs in teams: They must be transparent. Everyone can see everyone else’s OKRs along with progress. It helps keep people honest. It also helps avoid situations where teams are blind to others work. One team might be able to help another if they knew the challenges another team was facing. Or it is possible that teams have conflicting goals and are working against each other without knowing it. Transparency breeds accountability and alignment. This also helps encourage clarity in objectives. If everyone in the company can’t understand it, it may need some tweaking.
With these systems, you need to encourage a culture that supports safety. By that I mean if you are encouraging people to stretch for goals where they will fail 30% of the time, then people need to feel comfortable talking about mistakes and failures. transparency is easier when you know you will not be mocked or admonished for taking risks that might not pan out. On the flip side, you should also aim for a culture that encourages doing quality work and being a place where you can count on others to do so as well.
According to a study by Deloitte, the largest increase in job satisfaction and productivity comes with a company has clearly defined goals, written down, and shared freely.
I think OKRs are useful not only in a team setting but individually as well. After reading Measure What Matters I’ve begun applying the system to personal goals like finance. OKRs are a big shift that will not overhaul a company or a human overnight. Start small. Maybe you can set 1 – 2 OKRs on your own, or with your team. Try one for a weak or a month and see how it feels. If you are seeing positive results and getting your footing in systemized goal setting, you can begin to expand how often you use them.
I also would not recommend jumping in too quickly. Don’t try to define OKRs and commit and implement them on the same day. Take some time to reflect on what you are doing and how you’ve defined it. Another thing to remember is that OKRs can be flexible. Don’t give up on an OKR because its hard, but feel free to adjust definitions and key results if you find better ways to measure them. If you realize that an OKR no longer seems to have meaning or impact, kill it. If you finish your 3-month OKR in two, consider starting another one early.
By implementing these systems, you can overcome most of the common reasons people don’t achieve their goals. Let’s look at the list from before, and how you could approach setting goals differently now:
It’s not magic, but it’s also not easy. OKRs won’t magically make you a 10x productivity wizard or fix a toxic company culture, but it can give you a framework and a process from which you can make improvements.
Projects are sometimes doomed long before any designers or developers are brought in. Your work will never provide value or even see the light of day if you are working on something where the only possible outcomes are failure and mediocrity. But some can be saved. You can make it work. Your career will be better off if you can learn to avoid these projects and work within given constraints.
The first design decision on your project was made when a budget was allocated.Mike Monteiro, Ruined by Design
I use Mike’s broad definition of design: making decisions on how a system works is doing design. Stakeholders, project managers, and developers all design. Marketers could also benefit by realizing what they do involves design. Some developers don’t see it that way. They think they just write code. That’s wrong. We’re problem solvers, systems designers, and the people who need to help others navigate this ever-expanding technological jungle we are building. We can deliver better work and more value to those we serve if we understand our role in the design process.
Let’s take another look at the budget.
Various software projects can be attempted, sometimes even completed, for just about any budget. You could build a real estate listing site for $5k, $50k, or millions of dollars. You could spend $32 million building a holistic solution and not ship a damn thing.
Budgeting for software is like buying a house or a car. There is a wide range of options, and it depends on your situation at the time and plans for the future. And like major lifestyle financial choices, typically the budget is the biggest constraint we have to consider when building software.
Then our challenge is this: how can you help projects fit into a predetermined budget?
Different tech stacks come with different costs. If you are implementing the work one of the biggest factors may be your experience with it. Using the shiniest new tool is often not going to be the most efficient. Plenty of successful projects have been shipped with WordPress, PHP, or Ruby on Rails, and were successful.
If you can’t fit every feature in, you have to decide which features need to go. That’s part of the design. As a developer, it is your responsibility to help stakeholders understand the value of work that may not seem apparent. People will want you to do your job poorly, and call it “cutting features.” Security, accessibility, usability, and testing are not up for debate in this conversation. Those are features, those are taking care of the people that use what you build. Ignoring them makes you a jerk.
Instead, strong candidates for deferment or deletion are features where you say “we may need it one day”, or “what if…”. If you aren’t sure if you need it and you need to make cuts, start there. The more user research that has been done at the point, the more confidently you can argue for these changes.
If a feature doesn’t need to be killed outright, then you can always defer it to the next version. Keeping things for a version 2 or 3 means can be more palpable than saying they won’t be done outright.
If you can’t cut a feature, maybe you can pare down a feature. I love the term Scope Hammering. As Jason Fried puts it:
We take the chisel to the big block of marble and figuring out how to sculpt, nip, and tuck a feature into the best six-week version possible. It’s all about looking carefully at a feature and figuring out the true essence. Not what can it be, but what does it need to be?Jason Fried, How we Structure our Work and Teams at Basecamp
Make every form field, database column, and page defend its existence. For example, once I worked with a company that wanted users to enter their email, password, username, business name, age, and gender on a signup form. This raises all kinds of concerns, and opportunities to pare down scope:
Now we have a simple form with two fields. Its probably more effective with less and time and resources invested. And now that it is something that fits into a common pattern that brings me to my next point:
Something built from scratch has no more inherent value than an open source library, paid plugin, or 3rd party API within your application. One of the biggest mistakes I see developers make is to try and build their own solution when perfectly cromulent solutions exist. Often times, A pre-built solution will have been more battle-tested, and therefore reliable than building something from scratch. There are situations where it makes sense to build your own solution, but there has to be a good justification. Either there is nothing that exists, or what does exist meets your required use case (see previous two sections.)
Sometimes, you can cut features, reduce the remaining features down to their core essence, and find a way to piece together a solution with existing tools and services, and still not have a way to deliver what’s requested within budget. What do you do with stakeholders then?
You tell them.
Let me tell you a quick story. I once have several phone calls with a potential client. They wanted to start a new project that sounded interesting and seemed like it could do some real good in the world. I was excited, and so was she. Then, we get down to talking about price.
Me: “I think a project at this scale would be in the range of $15,000 – $20,000”
Her: “My budget is $500.”
I was crushed. I had put so much work into the project proposal and now I knew it wasn’t going anywhere. There’s another lesson in here about doing budget discovery, but that’s for another article. Instead, it didn’t matter what I designed. It was superseded by the design choice that was already made.
At this point I could have ended the call and marked the deal as lost in my CRM, but instead I took the opportunity to try and help this person understand the costs of what goes into software development, and tried to help them have more realistic expectations.
Project planning with stakeholders should be collaborative, not combative. If you can find alternate solutions that work within the budget, do it. If you can’t, have an honest conversation about it.
A project’s success lives or dies on every decision that is made along the way. Sometimes those decisions are out of your hands, but other times you have an opportunity to help those decisions end in conclusions that help a project move towards success. That’s the real job of a developer, not just to write code.
P.S. If you want to learn more about delivering software on time and within budget, you can learn more by checking out a sample chapter of Dependable.
|[content_upgrade cu_id=”43″]Get the bonus content: Dependable Sample[content_upgrade_button]Click Here[/content_upgrade_button][/content_upgrade]|
Why is speed important?
One of the most common recurring conversations I had with startup founders was how to get products and features out the door faster. Typically, all is running smoothly until it’s time to actually push your work out into the wild. People want to buy the poster that says “move fast and break things”, but they end up not doing the former, causing more of the latter. One of my core tenants in Dependable was to help move projects forward by making sure everyone checks egos at the door and gets out of their own way.
Fear is the project killer.
So why is moving fast important? When put on the spot recently, I blurted out “because life is short and we’re all going to die one day.” I thought I should try to collect my thoughts and phrase it in a less morbid fashion.
And to be clear, I am not an advocate of the “move fast and break things” mantra. Facebook lived by it & paid it no mind when they broke things like their interface, their trust among their users, the news media, or American democracy writ large. Moving fast without caring about destination or side effects isn’t speed, it’s haste and recklessness. It’s careening down the highway at 100mph, instead of picking the route to your destination with the quickest route and finding ways to cut out stops along the way.
So don’t be hasty, and don’t be reckless. But be quick, and be aggressive.
When people ask me how work is going, my response is “the good kind of boring.”
No pressing deadlines. No sense of urgency. A tried-and-true tech stack. Feedback comes in, and I implement changes. I send code off for review and review others — Features ship. Bugs die.
It’s not terrible. But, when my wife comes home and asks me to tell me about my day, I got nothing.
I’m not complaining, but “the good kind of boring” is still monotonous. Every job and every project has doldrums. Periods, where all there is, is the grind. Since these times are inevitable, what can you do to tolerate them better? I have found a few tactics that have helped me, but before that, here is why it’s imperative that you first take ownership of your boredom.
It is not your boss’s responsibility to make your job enjoyable, exciting or fulfilling. That’s on you. You don’t find a job that fulfills you; you find ways to build more fulfillment out of your work. Your happiness is more a function of your self-awareness and self-management than external factors. It’s part of your emotional intelligence. What’s causing your boredom, and what can you do to relieve it? It’s a learnable skill, just like writing, coding, or selling. Now on to those tactics.
Over the last few years, mindfulness has moved from Eastern religious practice to Silicon Valley fad. More than enough podcasts discuss it, so I won’t belabor the point here. Just know this: mindfulness doesn’t have to be a rigid morning routine or even a meditative practice. It can be 5 – 10 minutes of quiet, taking stock of your crazy monkey mind’s contents. We can all 5 minutes. Here’s a trick: The next time you are reading an article online, listening to a podcast, checking social media, or checking your email, don’t. Instead, take a moment to be present. Ask yourself:
Are you honestly working as hard as you can? Is there a way you can Daft Punk your tasks and do them harder, better, faster, or stronger? Actively trying to improve your skills increases engagement. Here’s how I turned one of my first gigs, a data entry job of endless Excel cut-and-pasting, into an enjoyable and fruitful exercise:
I hid my mouse.
Excel has roughly 37,000 hotkeys, of which I knew about 4. I decided to learn more
Are there other tasks you can do outside of your current position? Talk to your coworkers and see what they are struggling with. Another story: Part of working in automation is that you are in a constant state of obsoleting yourself. At one previous job, when I had automated all the significant sections of our marketing funnel at one company, I talked to coworkers about their processes. It turns out customer support had about 1.5 full-time jobs worth of tedious bullshit on their plate. I took on automating that and was able to get others away from their excel sheets so they could do something a little less boring themselves.
What if none the above work? No matter how hard you try to find meaning or challenge in your work, it still seems listless and dull. You doing as much as you can, and you can’t take on anything else.
That means you are fortunate enough to have a chance to work on your mental discipline. Just as emotional intelligence increases with study and practice, mental toughness increases with training. It works like any other way you increase knowledge or strength. You improve by pushing your limits. You’re bored? Keep being bored. Learn how to be bored. If it’s inevitable, then prepare. If you can’t improve your situation, better yourself.
“Help! I Landed A Job, And I Have No Idea What I’m Doing!”
Do you feel like you don’t know what you’re doing… like you’re a fraud?
Impostor syndrome is common in our industry.
Wondering when you’ll “just know” something and not be so reliant on Google & Stack Overflow? That day never comes.
Anxiety comes from chasing an ideal that doesn’t exist. Everyone relies on external resources. There is no “10x” developer that just knows the documentation from memory, that doesn’t have to reference.
Every single developer makes mistakes every day. Every developer has moments they have to reference the language docs for a particular function, even if they’ve used it 1,000 times before. (It was probably this one.)
What you know isn’t what’s important. What you get done is. Shift your mindset from “how good am I?” to “what can I get done?” It moves your focus from internal to external. Stop worrying about yourself, start worrying about others
Break the problem down. Solve the smallest part. Get something done. Start writing code before you understand. You don’t have to commit. Work with others, it’s a good reminder that everyone deals with the problem.
Most of your job is novel. You do things you have never done before and solve problems you have never seen for a living.
Everyone Googles. You can Google. I’m giving you permission.
All you have to know is the next actionable step, And go for it. Don’t read and study and noodle around the problem. Take action. Find answers as problems arise.
Most creatives freelance at some point. Either as extra nights-and-weekends work, filling gaps between jobs, or building your own business. I advocate for learning the basics of doing client work. It gives you immutable job security. If you know how to find clients and profitable work, you’re never unemployed. The ability to fend for yourself provides freedom.
At some point, you’ll face the decision: should I freelance or work full-time? It’s a personal decision, and there is no correct choice. The only wrong choice is being indecisive and not moving forward.
First I want to distinguish between freelancing and building a service business. Freelancing could mean taking side gigs here or there and making a quick buck. If you are considering client work as primary income, then you must approach it as building a business, not gig hopping. You’ll need consistent sales and marketing processes, and the ability to manage your cash flow.
Long term, my goal is complete financial independence. I’m aiming to have assets that generate enough cash flow so that no longer have required work. The simplest, most conservative strategy is to have enough investments such that 4% returns pays for everything. In the interim, work is finding the quickest path to that solution.
From that perspective, we have a starting point. “Will freelancing help me reach independence faster than full-time employment?”
But that’s just one factor. If all we did were optimize for retirement, we’d all end up working in finance, fueled by a diet of rice and beans. In the interim, it’s about optimizing both cash flow and lifestyle until you are at a point you are no longer required to work to sustain yourself.
But wait, doesn’t freelancing provide more freedom? After all, that is the origin of the term, Although I prefer the Westerosi version of Sellsword. In some ways, it does.
But it’s complicated.
One of the reason’s people see freelancing as appealing is they see it as working whenever they want as much they want.
Spoilers: it’s not.
Freedom isn’t a lack of structure; it’s the ability to build the structure. You have 50 hours of work to do this week. When are they? You are working with clients and will need to be available to them at some point. You aren’t completely divorced from the 9-to-5 world.
But deciding how many of those hours you work and when is still under your control. You also don’t have to ask anyone for vacation time or over time. If you want to make more, work more. If you need a break, scale back the client work you’re taking on. Which leads to the other part of freelancing freedom:
If you want to make more money at a full-time job, how do you do it? Overtime isn’t an option for a salaried creative, so you’ll have to ask for a raise. You may be able to get a few percentage points, but that doesn’t substiantially move the needle. Usually, the only option is to make a diagonal leap to get a higher paying version of your job at another company.
When freelancing, you set your rates and capacity. Nothing is stopping you from doubling your rate on your next project. You also have more say on how you get paid. You can get paid upfront or net 60. You can bill hourly or with fixed fees. Sometimes changing your pricing strategy is all it can take to increase your revenue by 70%.
But neither of these are the real freedom most freelancers are looking for. What you really want is…
Who you work for is often the biggest factor in job satisfaction. If you work at an agency that takes on cheap toxic clients and then attempts to get profitable with volume, you’re gonna have a bad time. When you’re running the show, you get to decide who you work for and what kind of work you do. If you enjoy working with clients in the music industry, you can build a pipeline focused on them exclusively. Don’t want to write PHP anymore? Don’t have to.
“You’ll never get rich working for someone else.”
This quote holds true in freelancing since you are working on assets owned by other people. But you can make more working for yourself than you can working for a company. I know several freelancers who make between $150k – $250k per year, and they don’t live in Silicon Valley.
If you’re freelancing and your only billing hourly, you’re doing it wrong. With your independence, you should be finding ways to leverage time and money, not just trade time for money. If you charge a flat fee, you can shave hours off of development buy shopping the shelf instead of building something from scratch. You can outsource tasks to virtual assistants or subcontractors. These tasks allow you to skyrocket your effective hourly rate.
Owning a business means owning assets and systems that generate revenue. When your freelancing, you are still responsible for some of the work. In some ways, freelancing is more akin to designing a job for yourself and not building a company. You still learn a lot about marketing, sales, and self-discipline. Being a freelancer means less time working on your craft, but more time sharpening your business acumen.
Contrary to popular belief, employment is the highest risk professional position you can put yourself in.
When you are an employee, it only takes one person deciding that they don’t want you to work at your position anymore and POOF, there goes 100% of your cash flow.
When freelancing, you have a diverse set of clients. In one of them fires you, you should only be losing a small fraction of your income. If you have systems for finding clients, you also have a quicker recovery system.
(Note: much of this part is based on my personal experience and is U.S.-Centric. If you live in a country where health care makes sense, your mileage may vary.)
You can often get better health insurance at a lower rate than you could being self-employed. There are also some tax benefits if your employer offers you a 401k.
Laws and banking systems aren’t set up with the self-employed in mind. Want a fun challenge for yourself? Apply for a mortgage while self-employed.
If my wife weren’t traditionally employed, we likely would not have been able to buy our first home. It’s easier to get good credit when the bank sees that you have ‘stable’ income. The combination of credit score, a W-2, health care, and a tax-preferred investment account means that full-time salaried employment provides you with a lot of life infrastructure.
With great freedom comes great responsibility. Sometimes for 100% of a project. On a tea, people have specialized jobs, and you have a support system.
I knew a freelance developer who was frustrated with all the hours he had to spend hustling. “I wish I could just put on headphones and code all day,” he said.
The, he should get a job.
If you’re a full-time dev, that’s what your boss wants. This means more time focusing on your craft.
People think that freelancing is higher risk, but in reality, it’s higher variance. You may have lean or fat months, busy and slow seasons. Everyone isn’t cut out for variance. Jobs tend to bring more consistency: you work roughly the same number of hours with the same group of people forever and ever. You get roughly the same amount of money every two weeks, which makes budgeting simpler.
When surgery was invented, the job title “surgeon” came with no modifiers. It didn’t matter what needed to come off or go in, you could see the same person. As medicine advanced, the job splintered. More knowledge meant increased complexity which necessitated specialization. Soon you would see one person for your war wounds and a different surgeon for tuberculosis. This process continued today, where we now have many different specializations.
I’m getting there. I’ve watched a similar splintering happen to designers and developers throughout my career. At my first job at an agency, back in 2008, those were the only two titles in the production department. At today’s software company, you will find a mix of front-end, back-end, DevOps, mobile, native, UX & UI experts. All taking orders from a product manager or project manager, sometimes both.
I’ve seen a new type of position begin to branch off. The marketing developer. Sometimes called a growth engineer.
Today marketing departments of a certain sophistication require a programmer’s skill. You can make progress faster when you don’t have to fight the product team to gain access to it.
Since this idea is new to me, I want to attempt to put a finer point on it.
It’s an interesting field. One I expect to see a lot more of in the coming years.
Looking for ways to spend less time doing parts of your job that you hate? You have three options:
I’m a minimalist. I like to take a Marie Kondo approach in business and life. Tasks get on out plate more quickly than they get off, and we don’t always stop to reflect and ask: “Does this work provide value? should we do it at all?”
Let’s assume for this article that the task has passed the sniff test. You can’t eliminate it. Then move on to the next two options: If a computer can do it automate, else we delegate the task to someone else.
There’s an important step before you can productively do either: document your process. Documenting your processes is something that you should be doing at any stage of your business, for a company of any size. I was documenting new processes on day 1 of my one-man shop.
Everyone has systems in their heads, whether they realize it or not. Do you have a morning routine? A strategy for handling your inbox? These are almost a process. However, I’m a firm believer that:
Ideas in your head are fuzzy and abstract. Getting a system out of your head and out into the real world has several benefits:
Many people get hung up here. Don’t. It can be anything that lays out how the job gets done. Some common examples:
You don’t have to pick one, choose the one that makes the most sense for the process at hand. Don’t try to force too much uniformity or rigidity. It also doesn’t have to be just one of these; it can be a mix.
Recently I had to consider the following facts:
So the conclusion was obvious. I shouldn’t be doing outreach; I should be building the outreach system. So I decided to tackle the problem in that way. The process is broken down into three parts.
By creating a process, I turned outreach into something fun instead of being a chore. Now I’m not just sending emails; I’m testing and iterating on parts of the process. I was able to shrink down the amount of time I spend doing the outreach so that I can spend more time doing work I enjoy.
Try documenting one of your systems today. It shouldn’t take you more than 20 minutes. Pop open a Google Doc, and write down the steps or create a template for just one task. See how much easier that task feels the next time you go to tackle it. How much more confidence you have. See how many minutes you save. Once you get over the hump and get started working on processes and see the benefits, it’s almost addicting.
tl,dr: no, you shouldn’t.
The United States Senate is on the brink of making a huge mistake. And it’s the same mistake that sinks software companies every day.
They want to rebuild a project from scratch.
It happens at software companies all the time, typically with new teams. They see a project full of legacy code that confuses and frightens them, and they decide they want to build a new codebase from the ground up.
Ripping out an existing, working system is always a costly mistake. Even if…
But don’t take my word for it. Take it from Stack Overflow co-founder Joel Spolsky in this essay about things you should never do.
Next time your company is thinking about repealing and replacing an existing project stop. You’re opening yourself up to once again face reasons projects fail #1, #4, #7, and #10.
Look for ways you can improve the existing project without starting over.
I’d like to share a story with you about my first conference talk, back at the end of September.
September 28th, I arrive in Norfolk, Virginia for the speaker’s dinner. Brennan invited all of the speaker’s out to a fancy restaurant before the opening mixer at the Double Your Freelancing Conference . This conference will be my first time speaking at a conference. To prepare for any presentation, I have a routine:
The talk is never scary; it’s the anticipation that breeds anxiety, even though I know I shouldn’t be. The organization is on point, what could go wrong?
Matt Inglot takes the stage to give his talk. His slides broke. Matt didn’t miss a beat. My heart did.
Something could go wrong.
It was also Gina Horkey’s first conference speaking gig too (Don’t tell her I said that). She went on before me. We would silently cheer each other one whenever we passed by in the hall.
“We got this!” “Do we have this?” “We got this!”
Gina takes the stage. Slides are out of order. She dropped her clicker. It snapped open. The battery fell through a crack in the stage.
After that, it was my turn. I was a bit shaken up, but it went fine.
If I learned one thing from DYFC, successful lifestyle business
people know how to party.
Of course, we talked shop too. You know what people said about
the day’s presentations?
cared about her bad luck. “All that happened, and she was still
People who gave a damn about the things we feared most: zero.
Why did our talks work at all?
… if the presentation is a user experience, then I am just a UI.
I am a UI.
And what’s a key attribute of a good UI?
It does not draw attention to itself.
And the moment I remember this is the moment I exhale and my
pulse slows. Because I am not important. What is important is the
experience they have. My job is to provide a context in which
something happens for them.”
We all took the stage aiming help people and did. We
disappeared. Broken decks and speaker pointers ceased to matter
because we ceased to exist.
Are you starting a new endeavor? Maybe you’re in the middle of
one, and you’re struggling to finish. Either way, try to take
yourself out of it for a minute. What problem are you solving for
who? Focus on that and success can find you regardless of rough
P.S. This letter originally appeared on the Tuesday Pulse Every Tuesday I could be sending you letters about shipping products that provide value to as many people as
possible, and you can get over the personal problems that stop you.
There are hundreds of project management tools out there, almost enough to convince software developers that they shouldn’t build another one. As a consultant, I form small teams frequently: my assistant and me, or pulling contractors together into a Large Project Justice League. I also have the privilege of working with many different companies, experiencing a smorgasbord of tools, techniques, and philosophies.
My Mother works in Elberton, GA, The Granite Capital of the World at a local Quarry. Here is their #2 best selling product:
I love companies like this, invisible enterprises that build something important to everyone. But this isn’t a letter about tombstones; this is a letter about their all-time #1 bestseller:
If you ever think you can’t provide value to the market, here’s a company making bank by selling tiny rocks on the ground, an abundant natural resource.
The quarry didn’t set out to be a tiny rock business. They set out to build beautiful monuments. The tiny rocks are a side hustle. Stonecutters work their craft, and tiny rocks just happen.
These rocks are gathered, bound, packaged, priced, and sold. This company took waste and turned it into a product that sells more than the product they showed up to build.
Every business has its tiny rocks: rubbish waiting to be butterfly-transformed into an asset. Here are some examples:
As a small business owner, resources are always tight. Without a lot of time or business capital, you need to get the most out of the resources you have. Look around you for tiny rocks, gold that you’re leaving on the ground. What have you been missing?
Sometimes when a client reaches out to me, they open with a question like this:
“My real estate company needs a website. We need show our real estate listings. How much will that cost, and how long will it take?”
Putting estimates together for projects is difficult even in the best conditions. It’s even harder when client’s are pushing for a proposal before you’ve had time to get all the details, or you end up having to spend a lot of unpaid time putting together a proposal that ends up getting rejected.
You know what one of the most common causes of failure is for software projects? You don’t have a plan. Unlike building with more solid materials in construction, you can start making software before you know what the hell you are doing. Writing a program roadmap helps you make decisions earlier when they cheaper, and give you a reference point to make sure everyone involved is working towards the same goals.
All businesses are inherently risky. Human beings are terrible at understanding and quantifying risk. Since most entrepreneurs tend to be human beings, this causes problems. Without having a clear picture of what risk is, how to identify it, and how to quantify it, making correct decisions about your business can be hard.
The biggest cognitive dissonance is that people confuse variance and risk. For the purposes of this article, I am defining variance as the variety and difference and outcomes of any given probabilistic event. A six-sided die has more variance than a coin since it has six different possible outcomes while a coin has two.
We define risk as the losses incurred based on the outcomes of one of those events. The greater the amount of loss and the greater the chances of that loss occurring increase the amount of risk in any decision.
Launching a new product can induce a lot of anxiety. If you have been working on your product for some time, it is easy to let the fear of uncertainty about public reaction take over. You might decide to push the launch the back until you can one feature a bit better, a part of the design a bit cleaner, or to fix one more outstanding bug. You end up pushing your launch back to next week, next month, or in the worst case, “one day”.
Apple just finished their 2015 WWDC, and there are some valuable lessons startups can learn from Apple’s marketing strategy.