The 4 Characteristics of Highly Effective Managers

The 4 Characteristics of Highly Effective Managers

I originally posted this in 2011 while I was managing 25 developers at Wells Fargo. The pop culture references are a little dated, but the core messages are still relevant.

“Oh, oh, and I almost forgot. Ahh, I’m also gonna need you to go ahead and come in on Sunday, too…” – Bill Lumbergh

Bad managers and bad management teams are everywhere. Movies and TV are filled with shows that rip on managers and/or put them in a bad light (i.e. Office Space, Devil Wears Prada, The Office, The Simpsons, etc.). These characterizations are often popular because, well, hasn’t everyone had a boss they disliked or disagreed with at some point in their lives?

The fact is that any shmoe can be a bad manager, but it is much tougher to be good, highly effective manager (note: the term “manager” meaning anyone in a position of leadership). I have been lucky enough to work for one the past 7 years and I have had the pleasure of getting to know many others as well. While I think that good managers come in different shapes and sizes, the most highly effective ones often display the following 4 characteristics.

1. Prognosticate like The Mentalist

The formula for the CBS TV show The Mentalist is pretty straightforward. Someone is murdered, Patrick Jane comes up with a theory of who did it and then he orchestrates a series of wacky and somewhat humorous events that ultimately reveal the murderer. Although it almost seems like Mr. Jane can read minds and see the future, there is nothing magical about what he does. His power comes from his ability to read other people, his knowledge of similar situations in the past and a knack for pushing the right buttons in other people to get a desired result.

Managers often need the same skills when they set goals and formulate product strategy. Sure, some people fall into killer products by sheer dumb luck, but more often managers need to do the following in order to reach their goals.

  • Understand Other People – This includes understanding the needs of their customers, the expectations of their superiors, the velocity of the team and the aspirations of individual team members.
  • Know the Past – Good managers use their previous experiences to get ahead of the curve and prevent potential future issues.
  • Orchestrate the Future – The great Peter Drucker once said that ”the best way to predict the future is to create it.” Highly effective managers at times need to come up with outside-the-box solutions to help the team achieve their goals.

2. Execute like Michael Weston

Any non-fake person thrown into all the crazy situations that Michael Weston has to deal with on Burn Notice each week would be dead in about two seconds. Each episode has Michael run into a number of surprise twists and turns that force him to think on his feet, focus on the task at hand and make quick decisions to overcome the latest set of challenges. Some of these skills include:

  • Prioritization and Multitasking – The best managers find ways to effectively work through dozens of tasks that all lay claim to be the highest priority without dropping the ball on any one of them.
  • Focus and Perspective – It can be difficult to focus when multiple business stakeholders each hold a gun to your head demanding to have their requests fulfilled immediately. Effective managers, however, stay cool and laser-focused.
  • Making Quick and/or Difficult Decisions – Being an effective leader means at times stepping up to make the quick, difficult decisions. Some examples include settling minor disputes, holding team members accountable and terminating a poor performers.

3. Develop Talent like Mike Krzyzewski

There are a lot of Duke haters out there, but even the haters respect what Coach K has been able to accomplish in over 30 years of coaching college and national team basketball. His strength centers around his ability to find and develop individual talent as well as gel talent into high-performing teams.

“A common mistake among those who work in sport is spending a disproportional amount of time on “x’s and o’s” as compared to time spent learning about people.” – Coach K

Even the best software development practices will fail if a team is made up of poorly performing, low-skilled individuals. The most effective managers take a page from Krzyzewski’s book of developing a highly productive team.

  • Recruit Top Talent – It’s pretty simple, really. The more smart, talented people on a team, the easier a manager’s job will be. Recruiting can be time-consuming and frustrating, but an investment in recruiting has the highest ROI of any other single action a manager can take.
  • Put Team Members in a Position to Succeed – After getting talented team members, a manager needs to figure out a way to maximize their productivity. This requires understanding the strengths and weakness of each team member and figuring out the best way to put all the pieces together.
  • Encourage Innovation – Nothing and no one is ever perfect. While a good manager typically has ideas about how the team and individuals can grow and develop, the best managers and companies find ways to create a culture of innovation. Some examples of formal programs to encourage innovation include Google’s 20 Percent Time, Hubspot’s Experimentation Framework, and Apple’s 10-3-1 Strategy. Formal programs may be impractical due to an organization’s culture, but good managers find ways to bring elements of these innovation programs into the team.

4. Fly Like Viper

One of my favorite scenes in Top Gun is when Maverick takes on his trainer (i.e. manager) Viper. Viper is an old fighter pilot that is no longer as skillful as he once was, but he manages to out maneuver Maverick and put him into a position where his wing man, Jester, can shoot Maverick down from behind.

The odd thing about software development managers is that the technical skills that got them into their current positions are often not used once they get there. No one expects that managers will be writing code all day, but as a manager loses technical skills, he or she has to rely more and more on other team members to make major technical decisions. There are a number of things managers should do to keep up their technical skills.

  • Audio Books, Podcasts, Twitter and RSS Feeds – Of course it is great to read technical books, but who has time? These days, techies have to maximize their time and jam knowledge into their brain in the most efficient manner. Driving to work? Listen to TechZing on your car MP3 player. Bored in a meeting? Check out what @mattcutts, @dharmesh and @guykawasaki are talking about on your Twitter app. Sitting on the pot? Scan through RSS feeds of the top 100 tech blogs using Google Reader on your iPhone.
  • Write Code – There is no substitute for writing code, but it becomes progressively more difficult for technical managers to do so over time. For those managers that are overloaded with administrative overhead, they need to force themselves to schedule at least a couple of hours a week to write code.
  • Test Your Skills – In addition to coding on a regular basis, it helps to test your skills periodically. One way to do this is to enter a coding competition with your team members or on a website like TopCoder. The point is not to prove that a manager is better than other developers. The point is that simply by going through the process of participating in coding competitions, a manager will be keep his or her coding skills sharp.


The reality is that there are many different types of effective technical managers. A manager does not have to excel in every area described here to be effective. However, those managers that can prognosticate, execute, develop talent and write code are more likely to be highly effective and create highly productive teams.

Tech Debt Ceiling

Tech Debt Ceiling

I originally wrote this post in 2011 before I accidentally deleted my entire website. I am re-posting it now because both the analogy I use (i.e. a debt ceiling) and the underlying issue (technical debt) are even more relevant than ever today.

There has been a lot of talk recently about the U.S. Debt Ceiling. Before you all hit snooze and click the back button as quickly as humanly possible, I am not going to get into any boring financial discussion. It’s just that while I was watching Meet the Press last weekend, I realized that there is an interesting parallel to software development and technical debt.

What is technical debt? I think Martin Fowler does a great job of explaining technical debt, but it is basically a metaphor to help illustrate how systems are affected by less-than-perfect changes. There are two common scenarios:

  • Unintentional Debt – This is when a developer inadvertently introduces flaws to a system. These flaws can come from lack of skill, lack of knowledge or just not paying enough attention. Have you ever hired a bad plumber to fix a leaky faucet and after he leaves faucet falls off or the pipes burst or some other new weird problem happens? It’s sort of like that.
  • Intentional Debt – In this situation, the developer knows that a change may cause issues. The imperfect solution is consciously accepted, however, because doing things the “right way” will take too long. The quintessential example of this is the Boston Big Dig where they decided to cut corners all over the place. For example, they decided to cement most of the tunnel without rebar to save time. I guess they figured ensuring the tunnels don’t collapse and crush thousands of people to death was a “nice-to-have”.

I am not sure if any of the following suggestions would help congress with the U.S. debt, but they may help you manage and reduce the technical debt within your systems.

1. Write it down

The first thing you need to do is figure out a way of effectively tracking when debt is added, what issues result from that debt and how you plan to address that debt in the future. This is easier said than done because our natural tendency is to avoid documentation and just focus on getting past any issues that come up (then have a drink and try your best to forget about them). This is one of those situations, however, where it pays to enforce a little bit of discipline within the team. Sure, it will require some extra effort from everyone to spend 5 – 10 minutes recording information periodically, but this effort will create a transparency that would not otherwise exist. Imagine if you used your credit card carelessly month after month without ever looking at a statement or having any sense of your financial health. A couple ideas for how to track of your technical debt:

  • Use Tools – Defect tracking tools (ex. Quality Center, Jira, etc.) or agile development tools (ex. VersionOne, Rally, etc.) can make it much easier to track technical debt. Most of these tools allow you to create custom issue types, associate those issues with other units of work and create workflows around issues. To go an extra step, you can use wiki software such as Confluence or MediaWiki to provide summaries and analysis of the technical debt being tracked.
  • Post-Change Debriefing – During the process of driving toward a goal, most productive developers are very good at blocking out anything and everything that would distract them from achieving their goal. That is a good thing, so simply modify your standard development process to include a post-implementation debriefing stage where you then can have the team document what was changed and what technical debt was eliminated and/or added. Note that for unintentional debt you may not see issues until further down the road, so be sure to document any debt from previous changes that was discovered as well.

Even if you don’t have a fancy tool or implement a new process, just do something. It doesn’t have to be perfect. The goal is to have tangible reference points to help make decisions rather than simply relying on anecdotal evidence.

2. Draw a Line in the Sand

Now that you have started to record technical debt for a particular system, you can set the Technical Debt Ceiling. This does not mean that technical debt can be measured to the point of knowing exactly when the “limit” has been reached. In fact, the reality is that in most cases the alert that a system is getting close to a debt limit comes from the general “feel” of the system owner. This general feeling typically is a result of things like production issues, support issues, development issues and (hopefully) a comprehensive list of technical debt that you wrote down per suggestion #1. Regardless of what you use to determine the limit, once you feel the system is close to it, you will basically need to make sure that the benefits for a particular change along with any technical debt you are removing is greater than any technical debt that is being introduced (i.e. benefits + debt reduction > new debt). You should probably try to do this for every change regardless of the debt limit, but the point is that it is even more important to follow this as you get closer to the limit. Essentially, the purpose of this Technical Debt Ceiling is to help provide justification for taking the extra time needed to do things the right way so that you can prevent adding more issues to a system that is already overrun with problems.

3. Clean Out Your House

My wife and I have a pretty good system for keeping my town home relatively clean on a day-to-day basis. We try to never leave dishes in the sink, clean up the baby toys each night before we go to bed and every Saturday morning we do a quick sweep and vacuum. Over time, however, my home has started to get wear and tear with things like kitchen tiles that break, scratches on the walls, the outdoor fence starting to fall apart, etc. The problem is that wear and tear can’t be fixed along with daily maintenance because typically those small things end up taking a couple of hours to fix and/or require some special equipment. So, what do I do? Well…usually nothing. Actually, I shouldn’t say that. I do write things down so I certainly have a very nice looking Google Spreadsheet with all the details of what needs to be done. But the problem is that someone has to actually do the work. Besides the fact that we are so busy with so many other things, when there is free time, it is like, “OK, would you rather watch the latest episode of Burn Notice orrrrr clean the gutter?”. Hmmm, let me think….well, I am exhausted and have a headache, but yeah, cleaning out the gutter sounds like a blast.

It is the same thing with software as we let technical debt grow little by little over time with the wear and tear of periodic changes. If you do nothing, it will continue to build up to the point where you are near that Technical Debt Ceiling and the issues within the system are causing a lot of pain within the organization. The thing is, though, it is truly hard to try to proactively put a plan in place to eliminate existing technical debt on a regular basis. The reason for this is that until we get closer to the Technical Debt Ceiling, the impact of technical debt is not painful enough in many cases to get a high priority on an organization’s backlog. It is way too easy for the business to just ignore technical debt for the sake of short-term tactical goals.

The solution is to establish some form of a Technical Debt Recovery Program. This means dedicating resources to debt reduction efforts on a regular basis as part of your standard processes. This does not have to be one specific person whose only job is to go through the technical debt list. It is much better to have every developer participate in some way. There are different ways you can do this, but one suggestion for Scrum-based teams is to try to have at least one debt reduction story with every other sprint. This would be a relatively small amount of time, but it would allow your team to get some traction. There are times, however, when it takes a larger effort to remove a particular debt. For example, moving an application off the mainframe. In those cases, you would need to get support for a larger project. If you do a good job tracking your debt, however, gaining support shouldn’t be a problem because we all work with reasonable, logical people, right?


Large, steadily increasing debt is not a good thing (duh). The situation with the U.S. debt illustrates how most people don’t think about debt until it is too late. Don’t make the same mistake with your software. Treat technical debt seriously and deal with it before it becomes a serious problem. If it already is a serious problem, aggressively work to reduce and eliminate it.


The Root of All Evil (in software)

The Root of All Evil (in software)

This is another post I originally wrote in 2011 before I accidentally deleted my website. I had to deal with a log of legacy code at Wells Fargo at that time, but tbh all developers struggle with technical debt to a degree regardless of how modern their stack.

What are you scared of? Snakes? Spiders? Sith Teddy Bears?

I am pretty desensitized having grown up in the era of great horror flicks in the 80′s, but there is one thing that never fails to create a pit deep in my stomach. It is when complex code changes are deployed into production for a system that already has a lot of outstanding issues. I hold my breath until those first users get onto the system and start using the modified code. To some degree, I feel this way with every production release, but there is more of a tangible fear when the target system is already messed up.

“Fear is the path to the dark side. Fear leads to anger. Anger leads to hate. Hate leads to suffering.” – Yoda

To get to the root of all evil in software, we need to analyze where this fear comes from.

Q: Why do you feel fear in this situation?
A: I worry that something will go wrong and the business will be adversely affected.
Q: Why do you think something will go wrong?
A: There have been times in the past when we thought we were implementing a simple, non-intrusive change, but once the change got into production there were major issues. So, the fear is not specific, it is just a general feeling that something could go wrong.
Q: Why not fix the root cause of those previous issues?
A: We do make small, quick changes to fix specific issues that occur, but the problem is that there are bigger, more general deficiencies within the system that continue to start new fires even as we put out some of the old ones.
Q: Why not fix these bigger issues before additional changes are made?
A: It is a matter of technical debt because the business wants something and they don’t want to wait so they are accepting the risk (i.e. adding technical debt) in order to get their change in faster.
Q: What specifically is it about the existing system issues that makes it so difficult to fix them?
A: Because in order to resolve the issue we will need to change a lot of code and touch a lot of components that would likely then require a lot of testing.
Q: Why do you need to change a lot of code at once?
A: Because it is not possible to change one section of code without affecting many other components. Everything is intricately tied together like one big ball of twine.


Tight Coupling

What my internal Socratic dialog reveals here is that true root cause of the challenges I face is the extreme tight coupling of code within the system. For the non-dorks out there, you can understand the concepts of tight and loose coupling by thinking about the difference between building a robot by welding pieces of scrap metal together (i.e. tight coupling) versus using Legos (loose coupling). When you weld metal together, you can do it quickly (assuming that know how to use a blow torch) and you can customize the shape into whatever you want. The only problem is that once you are done, the robot may be functional but kids would not be able to make any changes to the robot like putting on a new head or upgrading the robot’s arm canon. The scrap metal robot is what it is and if you want something different you likely need to toss it and get a new one. The Lego robot, on the other hand can still be built relatively quickly, but it is designed so that kids can customize the robot to their heart’s content. They simply switch out a couple blocks and they have a revamped, cutting edge robot.

It should be noted that not all tight coupling is bad, though. Each Lego piece (i.e. smaller component within a system) is made up of material that is tightly coupled together. The key is that at a larger system level there needs to be loose coupling at least among the major components so that they can be upgraded/replaced/removed without major impacts to the other parts of the system. Many legacy systems don’t even have this high level of loose coupling and that is why there are still so many Cobol-based programs out there today.

In 2008 the Governator tried to cut the salaries of 200,000 state works but he was unable to do it because California’s Cobol-based Payroll System couldn’t be changed fast enough. The state controller, John Chiang, basically said that the legacy “constraints” (i.e. tightly coupled code that couldn’t be modified quickly and easily) prevented them from achieving their goals. You can see this type of situation in many big businesses where the emphasis is usually on cutting corners to get to the quickest possible solution.


The root of all evil in software is the tight coupling within a system that slows down or prevents system changes. A system may have many other problems that come up from time to time, but the point is that most issues should be able to be quickly fixed and thus not cause any heart ache in the long run. If you are saying something cannot be easily fixed over an extended period of time, then it almost certainly mean the system is tightly coupled in some way. The reason why I can say this with a high degree of confidence is that if a system has the appropriate level of loose coupling, an issue within any individual component should not affect the other components. Problems will always be somewhat contained and limited in scope.

The 4 Characteristics of Highly Effective Developers

The 4 Characteristics of Highly Effective Developers

This was a post I wrote in 2011 that hit #1 on Hacker News. I accidentally deleted all my old posts at some point, so I am bringing it back. Some of the references are a bit dated, but most of the core messages still ring true today.

“We may be very busy, we may be very efficient, but we will also be truly effective only when we begin with the end in mind.” – Stephen Covey

It seems like everyone is busy these days. Especially when you are in IT. You are constantly being asked to do more and do it more efficiently. But, the important question is, how truly effective are you? In other words, you may work 100 hours a week and perhaps you do a particular task faster than anyone else, but that does not necessarily mean that you are effective.

Effort and efficiency are related to what you do while effectiveness is more about what you achieve. In other words, does it really matter how long or fast you work if you are not achieving your goals? Of course not! Hard work and intensity are valuable but only insofar as they help you reach your end goals. Effectiveness, therefore, is what organizations should look for in their developers and how developers should gauge their own abilities. I believe there are 4 primary characteristics of effectiveness for software developers.

1. Accountability

Everyone makes mistakes. Everyone. I mean, seriously, ev – ery – one. In one sense, saying that no one is perfect is like, “duh!”, but understanding and accepting this does not come naturally. When a software developer makes a mistake, the reaction of the developer typically falls somewhere between the following two extremes.

  1. The developer gets defensive and focuses most of his/her energy on deflecting blame and/or protecting himself or herself. After the problem is resolved, the developer does his or her best to make the issue a distant memory.
  2. The developer sees that there is a problem and focuses most of his or her energy on solving the problem. After the problem is resolved, the developer reflects on what he or she did wrong and what changes can be made to ensure a similar mistake is not made in the future.

Both Developer 1 and Developer 2 have some sense that they made a mistake, but their reactions to that information are vastly different.

In the mind of Developer #1, making a mistake is not normal. It is not something that can be explained easily to others without losing face. Developer#1 thinks that mistakes are a black mark against him or her that will never go away. In all likelihood Developer#1 will continue to make the same types of mistakes again in the future because he or she learned nothing from the experience.

Developer#2, on the other hand, may not like that a mistake was made, but he or she accepts the mistake and focuses on solving the problem. In fact, you could even say that Developer#2 typically owns the mistake. He or she openly and clearly says to everyone “yes, (this) is what I did wrong and (this) is what I am doing to fix it and (this) is why it will not happen again in the future”.

“When you make a mistake, admit it, correct it, and learn from it immediately.” – Stephen Covey

Over time, Developer#2 makes fewer mistakes because he or she understands what went wrong and he or she is able to make the changes necessary to avoid future recurrences. Because of this, the overall productivity (i.e. effectiveness) of the accountable developer continuously increases over time.

 2. Ability to Work with a Team

Prior to the start of the 2010 World Cup, it was common knowledge that the French national soccer team was in disarray. In spite of that team strife, however, the team was regarded as one of the best in the world with players like Thierry Henry, Frank Ribery and Patrick Viera. They were runners-up at the previous World Cup and many people expected them to contend for the 2010 World Cup. Unfortunately, things didn’t go so well.

  • Game 1: France 0 – Uruguay 0
  • Game 2: France 0 – Mexico 2
  • Game 3: France 1 – South Africa 2

France didn’t just lose and get knocked out of the tournament. They thoroughly embarrassed themselves. Despite all their talent, they couldn’t even pull off one win. Soccer is an unforgiving sport when it comes to teams that don’t have chemistry. Teams that work well together generally do better than teams that don’t work well together.

The same can be said for software development teams. You can do a great job of collecting the best collection of individual technical talent, but if they can’t work with each other things start falling apart and the overall team productivity takes a nosedive. Some of the symptoms that are pretty typical with dysfunctional development teams include:

  • Issues during testing or in production due to the fact that the developers were not in sync.
  • Time wasted arguing and complaining instead of solving problems.
  • Dissatisfied customers that don’t get the products and/or service that they expect.
  • Unhappy workers that quit or become less productive.

So, how can developers get better at collaboration and IT managers build teams that have synergy? I think it all starts with instilling a win-win mentality throughout the team.

“Win-win sees life as a cooperative arena, not a competitive one. Win-win is a frame of mind and heart that constantly seeks mutual benefit in all human interactions. Win-win means agreements or solutions are mutually beneficial and satisfying. We both get to eat the pie, and it tastes pretty darn good!” – Stephen Covey

There are many small things that people have to do to work well together, but if you don’t start with a strong foundation based on the win-win mentality you will face an uphill battle. Win-win represents the earnest intention to work well with others. People don’t just pretend to want their other team members to succeed. They actually do want them to succeed. When this happens, the overall productivity of the team can skyrocket.

3. Ability to Learn

“I know kung fu.” – Neo

I love how everyone in the Matrix can learn whatever they need to on the fly in a matter of seconds through a program that uploads the information directly into their brain. Totally cool. Whenever they encounter a situation that requires some new skill, they just tell the operator and then two seconds later…BAM! Neo needs to learn how to fight and after one sweet, 10 minute training session with Morpheus he is suddenly a martial arts expert. Trinity needs to know how to fly a helicopter and a couple of seconds later she knows how to fly a helicopter.

If only software developers had a way of doing the same thing in the real world, things would be a lot easier. The need to learn new things is just as strong in this world as it is in the Matrix. It is just that actually learning takes a little more time and effort. Highly effective developers usually display the following two characteristics:

  1. Desire to Learn – The developer understands that the skills and knowledge he or she has is only valuable insofar as they help achieve the desired goals. Therefore, whenever the situation requires learning a new skill in order to achieve a certain goal, the effective developer doesn’t think twice about diving right in and figuring out what is needed to properly equip himself or herself.
  2. Ability to Learn Quickly – There are no expectations that developers learn as quickly as Neo, but the faster a developer can pick up a new technology or learn a new system, the better. It is a skill unto itself to be able to learn quickly. The specifics of how this can be done differ from person to person depending on their how their brain is wired, but at a high level, it generally involves grasping the overall concept very quickly and then being able to filter out the important information from the less important information.

There is very little chance that new developers will know everything when they start a new job. Newbies will most likely have a learning curve as they get up to speed on the business and technical environment. Existing developers must also constantly work to keep up with the business and IT due to the fact that they inevitably change and grow over time. The ability to learn, therefore, is more valuable than any single technical skill on a developer’s resume and it is an essential characteristic of highly effective developers.

4. Passion

Passion is what drives all of us with what we do and is critical to the success of a developer. If you don’t love what you do, there is no way you are going to sit at a computer and write code for 12 hours a day. I love what I do (some would say borderline obsessed) and every single highly effective developer I have met has had a similar passion for designing systems, writing code and thinking about technology in general.


For employers, highly effective developers are very difficult to find. For developers, becoming a highly effective developer can be extremely challenging. In either case, a focus on these 4 characteristics can help a great deal. Employers should attempt to test for them during interviews as well as integrate them into the team goals. On the developer side, the more someone is able to show accountability, act as a team player, learn new information quickly and have true passion, the more effective he or she will be which should ultimately translate into various benefits, rewards and recognition.

Making Money (at a consumer-focused startup)

Making Money (at a consumer-focused startup)

Last summer I had a conversation with someone who works at one of the big tech internet giants. I mentioned that we were worried at my startup about the profit margins for one of our new products. He paused and then said something to the effect of “why do you care about making money?”.

The Case for User Growth

I almost laughed out loud when I heard that, but I knew exactly what he was talking about. For most consumer-focused startups in Silicon Valley, user growth is the primary focus and they actively try to avoid revenue. The moment you start making money is the moment you start getting judged on how much money you make. So, don’t make any money. Just focus on increasing the number of people that use your app on a regular basis.

In some ways this works well for consumer apps because it takes a lot of effort to make something that has mass appeal. If you focus on revenue too early, you may inadvertently cater to one niche of early adopters at the expense of a much larger group of people who would use your app under different circumstances.

The conventional thinking for consumer apps is that you can figure out how to monetize once you gain a critical mass of users. In other words, the path to success looks something like this:

  1. Create a free app
  2. Raise seed money on the promise of greatness
  3. Achieve hockey stick user growth before you run out of money
  4. Raise more money at a crazy high valuation
  5. Figure out how to monetize

This is the playbook for many consumer app startups in the valley and it has a proven track record. Just look at Snapchat, Facebook, Twitter, etc.

The Case Revenue Growth

Actually…wait a minute. Yes, Facebook went for user growth and has turned into a high revenue generating business, but what about the other examples? Twitter went public in 2013, but has never turned a profit and continues to lose about a quarter of a billion dollars a year. Snap went public last year and lost almost a half of a billion dollars in Q3 2017. And these are the success stories! A large majority of consumer apps don’t get close to this level of “success” and die off once their burn outpaces their ability to dupe…I mean…convince investors to continue to dump money down the drain…I mean…take a speculative position on a risky asset.

Obviously this is all a bit insane. But what is the alternative?

Well, how about focusing on actually making money instead? The great thing about this approach is that even if you don’t hit your aggressive revenue targets, you will extend your runway as a side effect. The longer you stay alive, the greater chance you will figure out your own path to success.

Yes, there is a fear that you won’t generate hockey stick revenue growth but…who cares? If you achieve profitability, then you an create your own destiny.


I have taken both approaches at various times in my career and perhaps this is the old fart in me, but I have come to strongly prefer revenue growth over user growth. I am patient and confident in my team’s ability to deliver. I don’t need immediate satisfaction. I know that if we just keep staying alive and we keep getting more and more swings at the plate, one of those swings will inevitably be a home run.



This is going to be one of those posts where I recommend doing things that I don’t necessarily do all the time. However, I really want to do these things. It’s just hard.

Focus at work sounds so easy. Just work on one thing at a time. Easy, right? Well…no.

First of all, we all have to deal with distractions. Life is full of distractions. Everything and everyone is vying for our attention. Trillions of dollars are spent marketing everything from video games to pizza to getaway vacations.

Second, for most people there are things that are more important than work (ex. family). Since work is not the single most important thing in your life, it will get pushed to the side from time to time.

Finally, even when we just talk about focus at work (i.e. not including external distractions or more important family matters), most people are hard pressed to truly stick to one thing. Sometimes this is a result of our desire to please others, but the really tricky situation is when there are multiple good options.

Most startups don’t die from starving (i.e. lack of opportunity). They die from drowning (i.e. trying to do too much).

In short, you don’t know focus until you have multiple really good opportunities and you figure out a way to ignore one so you can put 100% of your focus on the other. I struggle with this all the time, but at least I am somewhat self aware about this and try to take a step back to evaluate where I am at on a regular basis. Think about it this way:

What if you had two great options and you could succeed if you placed 100% of your focus in either one, but you will fail if you try to do both at the same time?

Product vs Commodity

Product vs Commodity

I love building software products, but sometimes it makes sense to treat a certain resource more like a commodity.

The definition of a commodity is a raw material like copper or primary agricultural product that can be bought and sold. There are of course many other services and businesses built on top of any commodity. For example, a manufacturer may buy a commodity (iron ore) and then sells steel beams. A builder would then buy the steel beams and sell a building. A real estate mogul may buy the building and then rent out space in the building. And so on.

ArcelorMittal (a steel company) really only cares about one thing when it buys iron ore: price. A new startup, on the other hand may evaluate many different factors when it comes to office space including intangible things like “vibe” and “network effect”. Part of the reason why co-working space renter WeWork is doing so well despite extremely high price per square foot is that they have developed a full product that appeals to young startups.

So, the big question is if you had a commodity like iron ore, should you sell it largely as is (i.e. you are selling a commodity) or should you try to transform it into something else (i.e. you are selling a product)? I think that software developers are naturally inclined to make everything a product, but the key decision point is whether the extra value you get from a transformation is worth the cost.

For example, let’s say you bought a commodity for $5. You could either sell it for $7 with $1 in costs for marketing, operations, etc. OR you could spend an extra $5 to transform it into something else that you can sell for $20. It may seem like the obvious choice is to spend the extra money and create a product you can sell at a higher price point for more profit. However, this isn’t always the right solution. The subtle thing that is often ignored here is that transformations carry risk. Markets can change and if you put yourself in a situation with a lot more overhead you may not be able to move quickly enough to avoid going in the red when your costs jump from $5 to $50.

The point here is that if you can truly make a profit off a commodity without much of a transformation, you may want to consider doing it. I love building products as much as any developer, but sometimes it may make sense to not build something complex and just expose the raw information or downstream tool without much on top of it. The contact information on GetHuman (for example, the Comcast Phone Number page) is built around a commodity. Namely, phone numbers and cheat codes for companies. We have at various times tried to turn this into a product, but nothing has been as valuable as just exposing the raw info in a very clear way. No login, no extra clicks, no downloads, no popups. Just the info the user needs in one shot.

2018 Tech Predictions

2018 Tech Predictions

I haven’t done this for a few years, but now is as good a time as any to throw out there some technology predictions for 2018.

  1. Voice-enabled App Explosion – 2017 was an amazing year for sales of Google Home, Amazon Echo/Dot and many other voice-based devices. The ecosystem for creating apps on these devices, however, is still pretty new. However, you are starting to see some super early adopters figure things out. For example, the KAYAK app for Google Assistant is really good. Expect many more like that in 2018 along with a lot of amazing innovation in the underlying platforms. It won’t be long before getting your business on these voice-based platforms will be as important as native mobile platforms.
  2. GraphQL Gets Real – The interest surrounding GraphQL is sky high. In the 2017 State of JavaScript Survey 60% of the responders said they have heard of GraphQL and are interested in learning it (compared to only 12% that actually know it and use it today). I am a huge fan of the technology, but also the general concept of having a standard framework for the back end. I think by next year’s survey, the percent of people that use GraphQL will double or even triple. Also, as a secondary part of this prediction, I think once more people fully understand the power of the underlying concepts behind GraphQL, there will be at least one similar competing backend framework that breaks out on the scene.
  3. Machine Learning Goes Mainstream – Similar to GraphQL, the interest among developers to learn ML currently far outweighs the actual legit production usage. However, even through this past year I saw I significant change in the quality and quantity of practitioners who attended my Boston AI Meetup. The knowledge base and tooling for ML is increasing and getting better every day. For example, if you haven’t already, you should check out MachineLabs which makes it really easy for newbies to get started and for anyone to share their ML models and code.
  4. Angular Finds Its (New) Groove – While I don’t think Angular will ever dominate mindshare like it did in 2013, I do think it will pick up steam for people in two specific situations: 1) when you want to have one team that builds one app that runs on multiple platforms 2) when you would rather buy into one end-to-end solution for all aspects of frontend development instead of piecing together your own custom stack of disparate technologies. There is a lot packed into this that I will have to expand on in a future blog post.
  5. SEO Gets Even Harder to Hack – I have spent the past month focusing a lot of energy on SEO for GetHuman (after taking a couple years off). At first I was really shocked at how bad Google has gotten (compared to 3+ years ago) at picking out obvious spammers (for certain search terms). Then I started reading about how Google is starting to rely more on Google RankBrain (an AI-driven system for processing search results). It typically takes a long time and a lot of data to fine tune large, complex Machine Learning (ML) models. When you see incorrect results with a ML model, it is not always easy to get rid of those results. You have to tweak the model in small ways so that you get rid of the bad results without adversely affecting the good results. Despite this challenge, I know many amazing engineers at Google like John Mu are hard at work on this problem. By the end of 2018, I predict there will be a major breakthrough and spam (i.e. low quality search results that are often trying to make a quick buck off you) will be eliminated from most search results once again.

Daily Planning

Daily Planning

Work stress for me doesn’t come from the quantity of work. I’ve got plenty to do and most of it needs to be done yesterday. A fact of life these days.

No, bad work stress for me comes from when I don’t have a plan. I can handle when I have a bit ToDo list, but I get super anxious when I don’t have a list regardless of how many things I need to do.

For this reason, I usually try to make sure I spend at least 10 minutes in the morning or the night before coming up with my daily plan. I usually already have some sort of list, but I need to go through that and adjust as appropriate. Here is an example of what my list looks like:


  • 1/11 – Patent || Waiting on lawyers to respond to our questions
  • 1/12 – Boston AI Meetup location || Waiting on response from Facebook
  • 1/12 – Peter || Gave him criteria for query; waiting to get data

Current ToDo

  • (family) Book flight to Cancun
  • (family) Call Sprint to get refund
  • (swish) Publis education video
  • (swish) Create plan for Budgeting Survey

Work Backlog

  • Update certificate
  • Security research

Family Backlog

  • Paint family room
  • Clean basement

Yes, I could put all of this in some sort of task management tool, but this list is more flexible than most tools and is meant for only the most immediate tasks you are working on. The larger backlog of tasks can live in Trello, Jira or some other formal task management tool. During those 10 minutes every morning when I am working on my daily plan, here is what I do:

  1. First, check the “Pending” section to see if there are any items with a date of today which need action. If action is needed, do it. Otherwise, ignore all the rest. Add new pending reminders here as appropriate.
  2.  Then delete anything from “Current ToDo” or any of the backlogs that no longer apply.
  3. Finally update the “Current ToDo” list with items (in order of priority) that I will try to accomplish today. This list should be reasonable, but slightly more than what I likely could accomplish in one day.



There is a natural tendency to overthink strategy.

The term “strategy” means a plan to achieve one or more goals. In many cases, coming up with goals is the easy part. We do it naturally on a daily basis with our never-ending stream of whims, desires, dreams and aspirations. The hard part for any non-trivial goal is coming up with a strategy that motivates us to immediate action and keeps pushing us along until the goal is achieved. All too often we make plans and may even start to take some actions, but then our progress stalls. Perhaps you may even try out a few alternate strategies, but they likewise stall and you don’t get any closer to your goals. Then you give up and/or stop trying.

The problem in most cases isn’t one of strategic skill but rather our inability to perceive certain types of progress. Painfully slow progress is still progress. Failure is still progress. Literally anything that keeps us moving and active engaged in good faith (i.e. we aren’t trying to make ourselves fail) IS PROGRESS regardless of the results.

The key is consistent action.

As long as your goal isn’t physically impossible and you don’t run out of time, consistent action in good faith will eventually lead to success.

I know it can be really discouraging when, for example, you go to the gym every day to lose weight but don’t see any results after a month of hard work. Or, you work yourself to the bone at a startup for a year only for it to fail. It can be really tempting in those situations to give up.

Don’t give up.

As long as your original goal remains a priority in your life, you need to just keep plugging away and working hard. That doesn’t mean to keep doing the same thing. Consistent action doesn’t mean the same exact action. It just means taking some sort of action. Learning from previous failures and making adjustments is part of the process.

To summarize:

  1. Stop overthinking strategy and just start doing something
  2. If your current strategy isn’t working, change it quickly and then keep going
  3. Don’t stop working toward your goal until either:
    • Your goal is achieved
    • The goal is no long relevant/important
    • You are dead

Consistency is power.