How often do you discuss the contrarian view of your company’s current situation? By keeping the status quo, you are inherently accepting some trade-offs and risks, and those trade-offs and risks can change over time due to external factors. What should you do to mitigate the risks? What external factors could change that would cause to make a change in your current situation?

Many times, you run into 50/50 trade-offs at this level that are really difficult to wrap your head around. At one point, Sears was the biggest retailer in the world, but they were unable to correctly determine that the growth of the internet and online retailers like Amazon would eventually overtake their brick-and-mortar and catalog business and drive Sears into irrelevance. Their error was that they missed the inflection points that should’ve led them to change course and adapt to a changing environment.

There are seemingly infinite case studies that have been done on Sears, and I’m not here to do another one. I instead want to focus on hypothetical trade-offs that they may have had to consider.

For example, e-commerce retail sales as a percent of total sales doubled from Q1 2000 to Q1 2003 (source). Granted, in 2003, only 1.6% of retail sales were online. Now we’re faced with a tough decision. We could say that Sears should continue to focus on its brick-and-mortar stores because 98.4% of sales are in stores. Or you could make the argument that the trends show that online shopping has the possibility of really cutting into the stores’ profits, so we should focus on building an online business that will win in the long term.

Here are some questions that I think would be worth discussing:

1. Where is the inflection point in the metrics that would cause us to change the status quo? What if e-commerce sales tripled instead of doubled in the same time period? What if X% of retail sales were online? What if the numbers varied by company or industry?

At this point, the best you can do is guess, but if everyone came up with an answer to the question and then you had a discussion about people’s view of the inflection point, that may lead to a more interesting discussion that digs deeper into the reasons for making a change.

2. How much capacity do we want to dedicate to mitigating the business risk? This of course depends on many things, like the health of the business, the perceived threats that competition poses, and the amount of volatility in the industry.

The problem is that you always have startups like Amazon that will go all-in on one approach (online retail), which means they are more likely to win if they guess right. They’re also very likely to fail if they guess wrong, but there are also other startups out there going all-in on a different approach hoping they win the lottery.

If you were in Sears’ position, you would need to decide how much capacity you want to dedicate to building out an online retail business. I think it’s more than that though – I think it’s important to know where the inflection points are where you should increase or decrease this investment and have a discussion about those inflection points.

The amount of risk you’re willing to take can also depend on the health and size of your company. If a larger company is doing well, they can devote more resources towards mitigating risk and still achieve good results in the core business. If a company is an earlier stage startup, they may not have the capacity to focus any resources toward mitigating risk and may need to go all-in on one approach and accept the risk.

3. What factors might cause us to make the wrong decision? This is where it gets really tricky, and where I think many companies go wrong. How much capacity do you put towards mitigating risk, which will reduce the revenue of your core business? If you’re a public company, taking action to meet quarterly targets may be the best thing for the company stock price, but could be detrimental to the business in the long term. Making a sound business decision may negatively impact the career prospects and compensation of people in the company. Senior leaders on shaky ground may be less likely to make a risky but correct decision because they can’t afford another perceived failure.

I’m applying these three questions to a business case, but you can apply the same principles to engineering teams as well. By discussing these questions, we give ourselves more data points to analyze because now we have several past assumptions that we can reflect on. Now the discussion turns from “we made the wrong decision a year ago” to “we made the wrong decision a year ago because we incorrectly assumed that X would change by Y% over the past year”. Now you can discuss why you made the wrong prediction about X, and how your predictions about other factors maybe were correct. If you never made a prediction about X, you wouldn’t have an opportunity to reflect on your decision making process, which is potentially more valuable than just realizing that you missed an opportunity.

“There are no solutions, there are only trade-offs; and you try to get the best trade-off you can get, that’s all you can hope for.” – Thomas Sowell

In software, we don’t often articulate trade-offs when we make a decision. We may make a pros/cons list and consider the options, but then when we make a decision, we just articulate the decision. Why do we do this?

For example, many companies at some point decide that they need to break up their monolith into microservices. Most people would agree that it wouldn’t make sense for a small early-stage startup to have a lot of microservices, and it wouldn’t make sense for a massive company to have one monolithic system. At some point in the growth of a company, you get to the point where this is a 50/50 tradeoff.

These are the most painful kinds of change because you’re trading off one set of problems for an equally painful set of problems, usually because you think it’s better in the long term. Making the change takes a lot of painful work, and big change is hard for people. If you decide to stick with the status quo, you’re still feeling a lot of pain. Either way, you’re likely to have many dissenters that think that the other way is better.

This is why you often see companies decide to switch from a monolith to microservices and then walk back the decision shortly after. Was it the wrong decision the first time? Maybe yes, maybe no, or maybe a new leader saw the 50/50 tradeoff as more of a 40/60 tradeoff. Changing your mind might be the best decision, but it still ends up costing a lot of time and money.

There are many non-technical examples I could talk about here as well, such as changes to planning processes, re-orgs, project prioritization decisions, headcount allocation decisions, etc. I’m sure you could think of many examples from your own company.

I think we can do better

1. Be aware of the negative trade-offs that you accept when you make a decision and make sure you have mitigations in place.

For example, you may decide to start using serverless compute because you want the ability to scale up quickly when you have spikes in traffic. The trade-off is that now your costs can explode unless you mitigate the risk by putting observability and controls in place to ensure that doesn’t happen. If all you focus on is solving the problem of handling spiky traffic, you could create a bigger problem.

2. When you’re articulating a decision, also include the counter-arguments, why you’re choosing to accept the trade-off that you chose, and any steps you’re taking to mitigate the risk.

This gives more context to the listener – if they have the opposite view, at least they know that you considered their side of the argument, are aware of it, and are potentially going to do something to mitigate the risk. There may still be disagreement, but you’ve shifted the discussion to whether we’re accepting the right trade-offs, which forces the dissenters to consider trade-offs as well.

3. When faced with a 50/50 tradeoff, consider keeping the status quo in place until the right choice is more obvious.

This may sound like a cop out, but it gives you more time to make the right decision and reduces the risk that a small change in some external factor forces you to change your mind. There are three typical outcomes to a decision like this:

• You make the right change and it ends up working out.
• You make the wrong change, and then you either have to spend more time to undo the decision or continue to march forward down a path that you know is worse, but the cost to go back is too high.
• You wait to make a change and make the right change a little late.

The cost of making the wrong decision can be extremely high. The cost of choosing slightly incrementally better trade-offs may incur a cost of change that far exceeds the benefits of the change. I would rather accept the pain of making the right decision a little late if it increases my chance of making the right decision.

Your work career is a unique thing. Many people choose a profession with minimal information in high school (hmm, that sounds fun, I have no idea what a normal day looks like in that profession, but I’ll try that). Maybe that first choice didn’t work and you ended up with your second or third choice before you found something that worked. However you got there, you then do that thing for 40+ years or so, and you spend a good portion of waking hours doing that thing. So needless to say, work is a big deal.

I think of my career in thirds. In the first third, I was learning, figuring what I wanted to do, gaining experience, meeting people, formulating new ideas, trying things. Towards the end, I’ll be focusing on the post-career transition and what I need to do to get there. But in the middle, the time I’m entering now, I feel like I’m in the prime of my career. I have the skills, knowledge, and experience to make a difference and do something great.

Act One

When you’re early in your career, you don’t have as much experience, as much knowledge, as many connections, and potentially as much financial stability. You’re still trying to figure out life, what it means to be an adult, what it means to be a spouse or a parent, or where you want to live. Maybe you don’t even know what job you want to have long term, or you’re trying to decide if you should go back to school. You don’t know what you don’t know, and you might not even know what questions to ask.

When I think about my career, I can pick out times where I made proactive decisions that opened the door to a set of opportunities that weren’t previously possible. For me, those decisions were moving to Columbus for my second job, speaking at conferences, and doing independent consulting.

When I graduated college in 2002, I graduated into a recession, and I had only one job offer. This meant I had to move to a city I hadn’t planned on living in (Ann Arbor, MI) where we didn’t have any friends, not to mention this was probably the last place a diehard Buckeye fan would choose to live (I grew to like it, for what it’s worth). I didn’t really have any idea what I wanted my career to look like, I was just glad that I had a job doing the thing I studied in college. It was a good job, I did well, and after a year of C++ I was able to move to .NET (back in the .NET 1.1 days when generics weren’t even a thing yet).

One of the biggest mistakes that many people make is that they stay at their first job too long. The problem with staying too long is that you never learn that the world is bigger than what you currently see, and you limit your learning potential by limiting it to the small field of vision that you got at your first job, which chances are wasn’t a top notch job anyway. (If you happen to start out in a great spot, good for you, you can ignore this paragraph.)

After 3 years, we moved to Columbus, another place where we didn’t have any friends, but it sounded like a cool place to live. I joined a local consulting company that (unbeknownst to me) was assembling a really solid team of developers, and I lucked into a great situation. It was here that I learned the value of the software development community, started this blog (in 2007!), and started speaking at conferences.

A funny thing happens when you start speaking at conferences – all of a sudden people think that you really know what you’re talking about, and that’s not limited just to the topics you were presenting on. I guess my presentations were good enough that people didn’t hate it (maybe that would’ve had the opposite effect). I think I did know what I was talking about, but at times it felt like people gave me more credit than I deserved, which I suppose isn’t a bad thing.

After 4 years of working at the consulting company (my second job), I went into independent consulting. Some people acted like this was a big risk. After all, if you don’t have a gig, you don’t get paid, and you have to worry about non-paying clients and taxes and Quickbooks and things like that. I did it for three reasons – I saw how the good people at our consulting company never had any downtime between assignments, how much of my bill rate went to the middleman, and I wanted a career path that led to growth but didn’t force me into a non-technical management role. So I found a way to make my own career path. It gave me more freedom to decide where I worked (I took a job working with my friends where I would learn Ruby on Rails and be 10 minutes from my house, even if it meant less money). I was no longer limited by career paths and promotions and job titles, I was only worth whatever people would pay me. It was a calculated risk – yeah, I might end up with no work (and no paycheck), but I earned more money when I was working to make up for it. Those were some of the best years of my career, and I learned a ton as a result.

Looking back at this stage, I wish I had someone to guide me along the way. A lot of things worked out well, but I lucked into some of it and wasted some time and learning opportunities just because I didn’t know what I was missing.

Act Two

Eventually I decided that maybe leadership roles weren’t just endless meetings, spreadsheets, and the abandonment of all of my hard earned technical skills. I made the leap into leadership roles because I wanted to find a way to create exponential value. If I were a great developer, I could make a big impact, but I was intrigued by the idea that in a leadership role, I could potentially help a large group of people level up and therefore make an even larger impact. I got to see some leaders do this, and the breadth and depth of their impact was immense. I thought I had some ideas that could work, so I went for it.

Leadership roles are a lot harder, mostly on the mental and emotional side. Sometimes you have to have the will to lead people in a direction with no one there to support you. You have to do the right thing, even when it’s hard. You have to deal with the ramifications of your mistakes. You have to create things from nothing, and figure it out as you go.

The main advice I give people in this stage of life is to maximize the upside. There are many opportunities that come along that in some ways may feel risky. But the real risk is that you let fear keep you from taking advantage of an opportunity that could lead to something great.

I want to maximize the upside because I feel like I can do something great. I might not always end up in a situation that enables that to happen, but I will learn something in the process. I need to keep trying to maximize the upside until I find a way to succeed, because I believe that one of these times I’m going to find a way to really make an impact.

That doesn’t mean that it’s going to come easy. Hard things are hard. Things were much easier earlier in my life, earlier in my career. I have a lot more responsibility now, a lot more stress, many more challenges, but also a lot more potential. Sometimes it feels like climbing a mountain to get to the top. In a way, it was a little simpler back when I didn’t even know the mountain was there. But now that I see it there, I don’t want to step back from the challenge.

I reached a turning point in my career when I started believing that I was capable of succeeding in a situation where I didn’t know that I was doing. We all feel comfortable when we’re in our sweet spot, where we’re doing something we’ve done for years, when we’re doing something that’s easy. When things aren’t easy, are you confident in your ability to succeed? Are you confident that you will be able to figure it out as you go?

It doesn’t matter if you failed at something in the past. All that means is that you tried one way and it didn’t work, which means you learned something that can help you be more successful next time, which makes now a better time than ever to be confident. We encourage our kids to have this “growth mindset”, but we might need it more than they do.

This is also a busy time of life for many people. Many people have families, with kids in school and sports and other things. There are a lot of things that are good, but it can also be tiring and stressful. While these things are hard, it’s also extremely helpful because it’s forced me to ruthlessly prioritize how I spend my time and make sure that I’m doing the highest value things, at home and at work. I feel like I have a much clearer understanding of my priorities.

Act Three

It’s hard to think about the last third of my career, because I’m not there yet. I imagine there is some aspect of seeing the finish line and figuring out how you want to get there.

I don’t ever want to mail it in and quit striving to be great. This applies to retirement as well. I might live 30-40 years after I retire, by then we will probably have many more ways to keep me alive. Sure, I’ll be more tired, my health won’t be as great. But I can’t imagine a life where I quit doing anything meaningful and just sit on a beach collecting seashells. If I’m still breathing, I want to be making an impact. That will look a lot different then I imagine, but I’m sure I’ll figure it out.

Early in my career, I was constantly learning and absorbing. The older I get, the more I see opportunities to give back and help others (while continuing to learn). I imagine that as I go, I will find more and more ways to pay it forward, invest in the lives of others, train the next generation of leaders, and maybe be able to make an impact at a larger scale.

Embracing the journey

Regardless of whatever stage you are in, it’s not about the goal, the destination, your dream job, your dream role, a job at a certain company, or any amount of money or notoriety. The journey is the goal. Every day, you have a chance to get better, to make an impact, to make a difference. That long series of steps will create a career trajectory that will take you somewhere, hopefully somewhere good. The important part is what you do today. What step will you take next?

Mental health is a frequent topic of conversation in our society today. While mental health issues have always existed, we are more aware of them now than ever before, and this goes for me personally as well. As I wrestle with the ramifications of mental health, I still yearn to see what’s on the other side of it.

I’m not only concerned about the mental health of the people around me, I’m also very concerned about my own. I find that it’s extremely healthy and helpful to be transparent, so I will do so here.

I’ve never felt like I’ve struggled with mental health. For most of my life I have thrived off the adrenaline rush that I get from being excited about life and the thrill of what might happen each day. I see challenges as opportunities and a chance to win and come out stronger on the other side.

But sometimes, life is hard. At this point, it doesn’t matter if your brain is chemically balanced. At some point the mental and emotional load can become a large weight that is very difficult to withstand. In my case, I have a wife and kids and friends and co-workers and a job and sometimes the combination of all of those things can be overwhelming.

There have been many times when I have been overwhelmed by the mental and emotional load, some worse that others. I notice when it happens now. Maybe this is what people refer to as a “nervous breakdown”, I don’t know. I notice when it happens because for the 2-3 weeks after the worst of it, I’m a lot more tired and I really struggle to get out of bed early like I usually like to, even if I try. At the end of the day, even if it’s a good day, I’m dragging myself up to bed.

These “mental injuries” are a lot like physical injuries. If you roll your ankle, depending on how bad you injure it, it might be a few weeks before you can run and cut on that ankle. With the mental injuries, I feel like my body goes into defensive mode and stores up energy in order to fight the next potential mental onslaught, leaving me with less energy to use (which doesn’t help things).

If a basketball player injures their ankle, they have to rest. They might really want to play and might feel like they could, but they risk injuring it further if they try to play on it. So they take care of their injury, and when it’s healed they can get back in the game. Some people feel like they can “push through” the mental injuries, just like you might push through being tired to get something done. Pushing through physical tiredness can be easily achieved with caffeine and a nap the next day. I’ve found that pushing through a mental injury will make it even worse and increase the recovery time.

While I accept these mental injuries, I don’t want to be mentally weak. I’m learning how to take care of the mental injuries. But what would be even better is if I could become mentally stronger. Basketball players do stretching exercises to prevent ankle injuries. In the same way, we have a chance every day to become mentally stronger.

I know people that are mentally weak. They tell you they are unable to do something or go somewhere because “it might stress them out too much”. To be fair, we all have things that we don’t like to do. But I don’t ever want to not do something worthwhile because it’s too hard.

When I think of mental strength, I think of the word resilience, the dictionary definition of which is, “the capacity to recover quickly from difficulties; toughness.”
Related to resilience is grit. We aren’t born with resilience or grit, but we learn it over time, and these are often mentioned as the key attributes of successful people.

I think I’ve become very mentally strong over the years. I don’t say this to brag, because I still struggle (as I am right now, in fact). It’s cliché to say that what doesn’t kill you makes you stronger, but that definitely is true. The question is whether you have the desire to get off the bench and get back in the game.

I’ve had a lot of adversity over the last several years, both personally and professionally. At times it’s tempting to wish that life could be easy. Most of my high school and college years were “easy” and exhilarating. It’s a different time now. What I’ve learned from all of it is that the key to success is not figuring out how to make life easy again, the key is learning how to thrive when things are hard.

Once I got to that point, a whole new set of possibilities opened up in my mind. I’m willing to take risks that I wouldn’t have taken before, because if I take a chance and end up in a pit, I’m confident in my ability to work my way out of it and make something great out of it. This means I have a much higher chance of success no matter what I choose to do.

Every day we get to wake up and take our best shot, and some days we will fail. But the great news is that the next day we get to wake up and try again at a new day. I implore you to keep waking up and keep finding ways to make each day better than the last. Be aware of your current mental limitations, but realize that you will have opportunities to stretch them. Run towards the chaos and then find your way through it, carrying those that need help. Think about resilience and grit and what those mean to you, and what they can look like in the future.

I will never stop fighting. I will get knocked down, many more times. But I will always get back in the game.

Source: https://dod.defense.gov/OIR/gallery/igphoto/2001829779/

I recently started a new job.

Before I go any further, I have to say that this is not another one of those “I just started at a new company and it’s great, and we’re hiring!” posts that make up 50% of LinkedIn. I’ve already posted and liked my share of those, so if that’s what you want, I’m sure you can find them.

So as I was saying… I recently started a new job (OK, I work at Upstart, now I’m done), and other than the initial struggle of going to work and feeling relatively unproductive due to lack of knowledge of the systems, it’s been so awesome. It’s a growing company, positive work environment, good people, fun challenges, and so on.

My previous job was a real struggle. We were going through an acquisition that was announced exactly one week after I started a new position attempting to start a data science team, so that dream lasted all of one week before the customary hiring freeze set in. So my feelings were anywhere from “am I going to still have a job in a week” to “wow doing data science is fun”, but the cloud of uncertainty won out pretty much all of the time other than when I was face deep in Python.

Prior to that job, I worked with the best friends I’ve ever had in a work environment. Yeah, the work was fun and challenging and I grew a lot in my career, and all that. But I what I really remember are the people I worked with. I still keep up with these people today even though I haven’t worked with them in several years now. I still meet many of them for lunch and go to their Halloween parties and hang out with them at conferences.

There’s a point somewhere in this rambling, and that is this – when you go to work, it’s not just a job. It’s way more than that.

I’m thankful that I enjoy what I do and where I work and I find instead of looking forward to Friday, I’m happy when it’s Monday too. I’m thankful that I’m no longer in the place I was a few months ago when I was trying to look for jobs while still going to work and trying to produce while I was wondering if I would have a paycheck the next week. I still remember where I was when I got the offer for my current job. It was if I set down a huge burden that I had been carrying, and it almost felt surreal when it happened. It’s a lot easier to get up early on a Monday now.

My wife unfortunately deals with chronic health issues. It’s a burden that she isn’t able to set down. I’m able to set it down temporarily when I go to work, but when I come home I pick up the burden again. I’m not going to complain about it, it’s the hand we’ve been dealt right now, and in many other aspects we’ve been dealt a pretty awesome hand. But there have been times when the people I work with have carried me through the year. Even just going to work and setting people and talking and laughing about whatever is a huge deal.

I’m sure I’m not the only one with struggles in life (we all have struggles). So every day when we go to work, we are able to help each other find our way through life, whether that’s dealing with hard times, advancing in our careers, or just getting that good feeling of camaraderie that comes from working together to achieve a common goal. I’m thankful for all of the people are have helped and are still helping me, and it makes me feel good to think that I’ve done the same for someone else.

Remember this when you go to work. You’re not just doing a job, you’re probably changing someone’s world along the way.

Why does it seem that so many organizations start out fast and lean and eventually devolve into a systematic morass of bureaucracy?

I’ve been asking myself this question a lot lately, because when companies are small, they don’t ever aspire to large amounts of bureaucracy, yet it happens over and over. Larger companies should seemingly have a lot of advantages over smaller companies (economies of scale, existing customers, well-understood value propositions), yet it’s the smaller companies that are growing exponentially and disrupting industries.

Maybe you’re the person working at the smaller company that’s growing fast. That’s great news! But there be dragons on the horizon.

Navigating the operating systems

We all live within an “operating system”, or a set of established rules that we believe will lead to good outcomes. For example, people might say, “If I work hard in school and go to college, I will be able to have a good career doing X and be successful.” We all live by these assumptions and count on them for our success, and this pursuit of happiness is an innate part of all of us.

When something comes along and threatens the operating system that we’re counting on, that is disruptive. Think of all of the factory workers that are saying, “I never missed a day of work and always worked hard, so why is my job moving overseas?” Those people were counting on a certain operating system and banked their success on it, which wasn’t a bad idea at the time, but then the rug got pulled out from under them. People generally don’t like that.

A major focus of the Agile movements of the last 15+ years has been around undoing the corporate culture of control and replacing it with empowered, cross-functional teams. In large organizations, the transformation efforts are typically at odds with the established system, which tends to fight back with such force that the Agile transformation efforts eventually get overpowered by the remaining establishment that doesn’t want to accept a new system.

Why do people oppose these transformation efforts so much? Because they’ve invested their career into that operating system. They staked their career on finding a way to work within an established operating system and advance in their career that way (and if your value is in your relationships and knowledge of internal systems, you can’t take those to another company). When you’re invested in an operating system, there is a temptation to believe things like, “I need to make sure I have control over more so that I don’t get cut if there are budget cuts.” That statement might give someone job security, but it doesn’t help the company create value.

I believe in organizations where as many as possible are directly involved in the creation of value, either as a doer or a leader. The doers are on the front lines doing the actual work to create things, and the leaders are thinking strategically, casting vision, finding new ways to create value, empowering teams, and distributing power and control as much as they can. As things grow, companies typically add the enablers in the middle to help coordinate it all.

This is not to say all middle managers are bad. After all, I am one (by title, at least). :) Here’s the crux of my point – the more people are confident in their ability to get another job at the same level, the more they will behave in the best interest of the company. There is a really good job market out there if you’re a developer or if you’re a good leader, but there’s not as much of a job market for the middle manager who only knows how to navigate the political landscape at Company X and knows Company X’s systems. All of us (myself included) are trying to figure out the operating systems in our world that will enable us achieve success.

So what does your organization’s operating system incentivize people to do? If you’re organization feels overly political and you feel like everyone is trying to grow their fiefdoms, think about who set up that operating system. Why are you surprised when people are trying to invest in your operating system to advance their career?

Blurring the lines

In many organizations, job roles and functions are very well-defined (implicitly or explicitly). Developers write code, QA testers test code, managers/directors/etc. are the leaders that drive the bus. This creates a pyramid structure with a few senior leaders at the top, the doers at the bottom, and several layers of enablers in the middle to execute the leaders’ vision and manage the doers at the bottom.

I think we need to blur the lines. I think that the goal of the leaders at the top should be to push as much context and leadership down to the people below them. Senior leaders got to their position for a reason, so they need to use their leadership talents to train and coach the next generation of leaders.

In addition, I believe we should pull problem solving up to the higher levels of the organization. This doesn’t mean that everyone in the organization is writing code, but if leaders are delegating and empowering others to lead, they now have time to focus on other things, including helping deliver value to the customer. So if an opportunity comes up, maybe a leader has time to dive down in the weeds and take advantage of it.

What this does is flatten out the pyramid and gets everyone closer to the creation of the value. This operating system incentivizes people to either be directly involved in the creation of the value or to empower others to be even more successful.

Multiplying your organization

I think most people would agree that smaller teams/divisions/organizations tend to offer more autonomy, while the large, bureaucratic organizations have more red tape, dependencies, processes, and other things that reduce autonomy. For example, you may decide to centralize a job function (read: make things more efficient), but the trade-off is that you are sacrificing autonomy to do it. I’m not saying that centralizing things is always bad, but I do think that people making those decisions are often undervaluing the autonomy that they are sacrificing.

The product-based mindset that more and more companies are adopting these days is awesome. What it creates is a world of autonomy where product teams can work with engineering teams to deliver value quickly with minimal dependencies. It gets even better when you change the budget process around to fund products in real time, so now the product organization is empowered to spend money as they see fit. On the engineering side, the cross-functional team has fewer dependencies that stop them from releasing to production, so value is delivered to customers faster.

The biggest reason that I think product-based organizations thrive is that things were made smaller. A product organization is essentially a mini-organization within a larger organization, with everyone working towards the same goal. But product teams won’t thrive if you don’t give the lower-level leaders of these organizations the autonomy to make a difference. This leads to exponential scaling, and the larger organizations will be able to support larger numbers of smaller product mini-orgs.

Exponential growth

In today’s world, every organization needs to find a way to achieve exponential growth or they risk becoming obsolete. Does your organization’s operating system encourage exponential behaviors (empowering, multiplying, innovating) or linear behaviors (risk aversion, amassing influence, building fiefdoms)? Depending on how you define your operating system, people will work within the parameters that have been defined, so we need to be proactive and make sure we’re encouraging behaviors that will allow an organization to grow and continue remain nimble over time.

I’ve worked in many environments over the years, and it seems like one constant in IT is that teams always seem be behind on projects or overworked. Teams are scrambling to meet deadlines, don’t have enough time to do things the right way, and amass a bunch of technical debt in the effort to meet a date, and then dream about what it would be like to address that technical debt while they move onto the next project that will inevitably be behind.

How does this keep happening? I’m guessing that most of us don’t work for slave drivers that ruthlessly pile work on us (if you work in an environment like that, I’m sorry).

I’d like to think that most of us work for good people. The people that we work for look bad when we’re behind, and it’s hard for them to go to their bosses and have to explain why the teams underneath them couldn’t hit a deadline.

So how does this happen? And how much control do we have over it? I would argue that it’s mostly on us as teams and leaders of teams. Here’s what I’m doing about it.

Defining normal

Your team gets to define what is a normal pace for your team. This often seems very arbitrary.

Let’s say that you’re on a project where you need to work 60 hour weeks to meet a deadline. Clearly if you’re working 60 hour weeks, you’re behind. In this situation, everyone settled on 60 hour weeks as “normal” for this team on this project. Given that you’re behind, it would be beneficial for the completion of the project if you worked 100 hours a week, but that’s outside of the normal that you’ve defined. So while the project feels out of control, everyone settled on some form of equilibrium.

I realize that I’m over-simplifying things a bit. If someone imposed a deadline on you, or you committed to something and drastically underestimated, maybe you feel stuck in this situation. Or maybe you aren’t pushing back enough or doing your part to define normal.

Most teams have long backlogs, and inevitably there will be pressure (malicious or not) to add more work to the schedule. You get to control when you say yes and when you push back. This is how you settle on “normal”, and it depends mostly on how the team responds to requests.

Let’s look at this another way. Let’s say that your team works 40 hour weeks and no one is overworked, yet you complain that you don’t have time to address technical debt. You give reasons for this like “management won’t let us” or “the business won’t let us”. But if you’re an agile team, isn’t your team doing the estimating? Don’t you have input on how much you commit to each sprint? Given that you’re not working 60 hour weeks, it seems like people are being reasonable with work/life balance.

Once again, you get to define normal. If you can complete 100 story points in a sprint and you want to use 10% of your capacity for technical debt, then for the next sprint just tell the business they have 90 story points to work with. If someone questions you, you answer that you need to keep up with technical debt in order to continue to move at the speed that they want you to move at. If you have deadlines that won’t allow that, when you get to the point where you define the next deadline, take things like technical debt into account.

Use the right data to improve your estimates

I find that many teams don’t track data to help them get better as estimating, or they track the wrong metrics. We all know that estimating is hard, but planning is a simple data analytics problem, and it’s not even that difficult.

If you wanted, you could call me up and I could come in and estimate your project for you. Chances are it wouldn’t be a very good estimate compared to what you could come up with. Obviously, that’s because you would be drawing on past experience to determine what will happen in the future. So why don’t we do more to learn from the past?

A lot happens during a sprint, and these things can be tracked. Please understand that I am talking about team-level metrics, not individual metrics or anything that would be used to compare teams. Here are some things that you can track:

• Team velocity for the sprint
• Cycle time
• How much work was added to the sprint after it started
• How much work was removed from the sprint after it started
• How much work carried over to the next sprint because it wasn’t complete
• How much work that was included in a sprint was already partially done because it carried over from the last sprint
• How much production support came up during the sprint
• How many developer days you have in each sprint (taking into account PTO, holidays, etc.)
• Unexpected days off during a sprint (e.g. people getting sick, emergencies, etc.)
• How much work in the sprint was due to bugs that would found during the sprint
• How many story points ended up in an epic when it was complete (compared with the number you thought it would have when you started)
• What areas of the system tends to have the most defects
• How many bugs are found in production vs. before production
• For a given project (or type of project), how much work ended up getting added to the scope throughout the course of the project, and why

I could probably keep going. Tracking things like this tell me things about my project. You can estimate all of these granular things and use those guesses to make better estimates about larger things. These aren’t things that need to be shared with anyone outside your team. These are things that you use to get better.

I find that many teams track very little data about their project. Then when they have to give an estimate for a project, the odds of them guessing wrong are a lot higher, and the consequences are difficult.

Having empirical data also gives you a leg to stand on when someone questions your estimate. If someone questions why you think something will take so long and you can respond with, “I know this seems long, but we’ve done the same kind of thing 3 times before, and this is how long it took those times,” that’s a very compelling argument. Because if you get into an argument over whether your estimate is correct or the boss’ idea in his head is correct, the boss often wins unless you have data to back your estimates up, and data is really hard to argue with.

We are inherently overly optimistic

We all want to succeed, we all want to get projects finished early. We all want to please our bosses, stakeholders, customers, and users. But most people have a tendency to be overly optimistic when it comes to estimating.

Developers are often really bad at this. I can say that because I’ve been very guilty of this. Some of you reading this may have worked with me and are chuckling right now. I promise, I’ve gotten better.

Developers often estimate based on the rainbows and unicorns scenario where they don’t hit any roadblocks, the requirements are bulletproof, they don’t get interrupted by production support, and the code is easier to write than expected. In reality, some or all of things things don’t work out. You don’t know which thing will go wrong, but something usually does, so we need to start including that in estimates.

Our feelings are fickle, so we need to resist the urge to give an estimate that will make our boss smile. What will make them smile even more is having a project completed on time without having the shuffle their schedule because you couldn’t get your part of the project done.

Stop counting hours

Our team has completely stopped estimating anything and hours and switched completely to story points. This probably deserves a blog post of it’s own.

I estimated in hours for years. For awhile I thought that story points were only for situations where you had very little information about a project and you needed to estimate it. Now I think that we’re pretty much always in a situation where we don’t have enough information to estimate in hours.

Story points are nothing more than a relative scale where work is estimated relative to other work, taking into account complexity, uncertainty, risk, scope, and effort. As a result, crazy things are possible. For example, our team has estimated 75 stories in 30 minutes. Many of these stories had nothing more than a title. We had no idea how many hours those would take, but we had a pretty decent guess of whether something was harder than something else.

Have you ever been in a meeting where someone in a leadership role (manager, tech lead, project manager, etc.) was arguing with a developer about how many hours a feature would take to develop? With story points, there is no argument. What difference does it make if a developer thinks something is 5 story points vs. 3 story points? It’s just an arbitrary number that has no effect on how long the actual work (done right) is going to take in the end.

Hour estimation leads to developers making bad decisions. For example, a story is estimated at 10 hours, and as soon as a developer has spent 10 hours on the ticket, they feel like their time is up, and they start cutting as many corners as they can in order to get the work “done”. If you use story points, there is no artificial hour limit to distract people from doing the right thing.

Estimating in hours also encourages project managers to try and account for how every hour of the day is being spent. This often leads to measuring developers against each other (or perception that that could happen). Inevitably someone (with good intentions maybe) starts tracking actual hours vs. estimated hours to get better as estimating, but this encourages developers to cut corners even more so that their personal numbers look better.

I really don’t care about any metrics that aren’t at the team level. On most teams that I’ve worked on, the best developers often get less done than others on the team because they spend more time helping others, planning, designing, and other things that don’t get added up to hours spend coding to complete a ticket. But those efforts do a lot to contribute to the success of the team!

Expect the unexpected

Unexpected things go wrong all the time. Production support happens, people get sick, team members leave the company, unexpected scope gets added to your project, users find high priority issues that they need fixed ASAP. And all of this stuff can be estimated and tracked.

Last year, we had 6 people leave our team, and we onboarded 6 new people. 2 developers were each out close to 3 months on long-term leave. I can sit there and make excuses for how these things shredded our timelines and made them unreasonable, or I can attempt to plan for them.

Look, people don’t stay in jobs as long as they did 30 years ago. This is not a surprise. If you have a team of 10, how many do you think will still be on the team a year from now? Probably not all 10. Do you have time in your schedule to absorb the loss of 2 team members and the onboarding of 2 new team members? Those things are a massive drain to your productivity, and they’re also very likely to happen.

On many projects, there are a lot of unknowns, and both you and your stakeholders are going to find many other things during the course of the project that absolutely have to be done. Once again, you can blame scope increases for being behind, or you can estimate how much you think it will happen and refine those estimates over time. This is not arbitrary schedule padding, this too can be an educated estimate based on actual historical data.

Continuous improvement

If you’re leading a team, you owe it to your team to find ways to get better at estimating. After all, their work/life balance is on the line, and your reputation as a leader is as well. I personally take this very seriously and am continually trying to find ways to get better at it. The success of your team may depend on it.

The world as we know it has changed.

Technology has changed everything. Automation has caused thousands of jobs to disappear. Entire communities have been rocked by the closing of factories because robots or foreigners could do it cheaper. The American Dream that so many people clung to is gone.

What American Dream?

The American Dream gave people the assurance that if they worked hard, they could get a steady job that paid middle-class wages, and they would likely have a job until their rode off into retirement with a pension. This system helped millions of Americans make a good living and improve their living circumstances. Not only that, the system offered stability, which is a huge deal when you’re trying to support a family.

What happened between now and then? Many of these middle-class manufacturing jobs are gone, and the robots and data analytics are coming for more and more jobs every day. Income inequality between the CEOs and the average worker is increasing. Technology has created better ways to achieve results, and many of the old ways of doing things have been left behind. This can be really unsettling for many people.

The American Dream was a system that people bought into because it gave them a path to improve their life and achieve success. People went to college to learn certain skills that they thought would be needed for their entire life, so when those skills suddenly become obsolete, it’s natural to feel like the rug got pulled out from under you. Not only that, you see many other people succeeding in ways we’ve never seen before (and with smaller numbers of people getting larger sums of money).

Think of the factory worker who never missed a day of work, always worked hard, worked extra hours when needed, and now their job is going away because a robot can do their job. What about all that hard work? Wasn’t that worth something to their employer? The answer is yes, but not enough compared with the power of the results that technology brings.

The Results Era

Whether we like it or not, we live in an era where results matter. In reality, results have always mattered. The difference now is that technology has provided ways to achieve exponential results.

In the old days, economies of scale were a thing, and the average American couldn’t just stand up a factory and build a manufacturing empire. Now you have a few people in a garage creating a phone app and becoming billionaires. They earn those billions because they produce results and value, and they can do it at an exponential scale.

There are a new set of skills required for the internet era. This strongly favors those people that understand technology, and punishes those who are still trying to create value in a linear fashion. The ever-changing landscape means that a higher premium is placed on people who can navigate the uncertain landscape (therefore, C-level salaries are increasing).

Is this fair? Of course not. But the results-oriented economy has no feelings and reality can be pretty harsh.

I’m Good, I’m In Software Development!

For as long as I’ve been in the working world (which is almost 20 years now), software development an related jobs have been at the top of the list of professions with the best job prospects in the future. For those of us in these jobs, this is fantastic! We can just sit back and coast to the finish with our ever-increasing salaries and job opportunities, right? Wrong.

The world is not done changing, and the industrial revolutions are coming at us exponentially fast. Many people call coding the new blue-collar work — it’s the low-level work that is done by millions to build our value factories (systems and applications). Could something make that blue-collar work obsolete? (You could argue that this already happens, just look at the turnover in JavaScript frameworks every 5 years. I remember when I thought Silverlight was going to be the future.)

Many Americans are being forced to reinvent themselves because their job went away. Why couldn’t this happen in software engineering as well? This is already happening, think of how many engineering managers and developers with experience in outdated languages are out there struggling to find a job.

What do we do about it?

I’m not here to make political commentary, you didn’t come here to hear my opinion on that. There are likely things that politicians will do to help. But we need to face the new reality of the results-oriented technology empowered world, and we need to be proactive about it.

Get good at things that the robots can’t do

There are many things that technology still can’t do. Technology can’t be empathetic, or care about people. Technology can’t sit in a room with people and listen to them and understand how to solve their problems. Technology can’t be there for a co-worker who is dealing with some struggles at home and help them through it. Technology can’t think strategically and anticipate changes in trends in the marketplace. Technology can’t inspire others to achieve greatness.

Emotional intelligence has always been important, but it’s going to become increasingly important in the future. We’re not really good at finding emotionally intelligent workers (how many of you focus on this in interviews?). Our job postings still start with X years of experience in some technology that you can learn by watching a Pluralsight video, but we have no idea if our interviewees can relate will with people or if they’re confident and secure in who they are.

Keep learning

I don’t wonder if I will have to reinvent myself, I wonder how many times I will have to reinvent myself. This is inevitable, even if you are on the cutting edge of technology, if you go work 3 years somewhere on the same application (which most of us do for at least that long), by the time you’re done, you will probably already have some big holes in your resume. Technology changes ridiculously fast these days (and it’s not slowing down).

If you’re not willing to learn, you are going to get left behind. Whether that’s “fair” or not is irrelevant, it’s a fact in the world we live in today.

If you’re an engineering leader, you need to keep this in mind as well. Are you encouraging your teams to adopt new technology that will help their careers, enable more exponential benefits, and help you recruit those workers trying to fill those holes they found in their resume? Are you ruling out candidates that don’t have enough experience in the technology that you use or are you trying to find the smartest, most emotionally intelligent, and best learners that you can find? Are you encouraging your people to keep learning, and are you giving them the time and opportunity to do it? What matters more to you, the results that your teams produce or how many hours they spend sitting in their desk chair?

Focus on exponential technologies

Some technology provides benefits that follow a linear path – you add a feature, and it provides some incremental benefit to those that use it.

Other technology provides exponential benefits. For example, computers can analyze large data sets to make decisions in ways that an army of humans never could, and if you need it faster, you just click a few buttons and your cloud provider can give you as much processing power as you can afford. These are exponential benefits, because you literally cannot hire enough people to do the same work, and even if you could, it obviously wouldn’t be cost effective.

This probably should cause many companies to change course. Find the things that provide linear value, and cut back investment on those things so that you can focus on things that provide exponential value (or support things that provide exponential value). Reporting and data analytics have traditionally been an afterthought and something that gets done eventually after the main product launch. Today we should be building the system because it helps us gather the data that feeds our exponential data engine.

The old world is not coming back

Regardless of how much people long for the old system, it will never come back. Whether we like it or not, this is the world we live in, and we need be ready for it. Staying ahead of the curve is challenging, but if we are able to achieve exponential results, we will be able to do greater things than ever before.

By now we are all very familiar with the rapid pace of disruption in the world today. We can all remember the “old days” when you couldn’t just take out your phone and have a car show up or when you had to go to a store to rent a movie. But what would happen if you were the one being affected by the disruption?

For many working people, that is the reality. Many manufacturing jobs have been taken over by robots, taxi drivers are out of work, and it takes fewer workers to get the same amount of work done due to technology advances. But you say, “Oh, I’m in tech, and the demand for us is higher than ever.” That’s true… now. But even our world could get rocked in the same way.

Let’s think about today’s disruptions for a second. People have been disrupting industries all the way back when they invented the wheel. Why is the impact of the disruptions so much greater now?

The difference in today’s disruptions is that people are finding ways to enable exponential growth when everyone else is stuck in linear growth. Uber can add a virtually unlimited number of drivers much faster than taxi company can hire taxi drivers. Airbnb can add a virtually unlimited number of rooms, while hotel chains have to build new buildings. Machine learning is able to process a virtually unlimited amount of data faster than humans ever could.

So what about software development? I don’t really expect that coding will go away anytime soon, and I expect it to increase. But for as long as computers have been around, we’ve been building software in a linear fashion, one line at a time. So I don’t think it’s a stretch that sometime in the near future we find ways to exponentially increase the impact of the software we build.

If and when that happens, things will change. Maybe it’s just the languages that we use, or the tools we use to build them, or maybe data plays a much bigger role.

Wait a minute… this is already happening!

It turns out that the future is now, and things are already different. Ten years ago “data scientist” wasn’t a job title you saw very often. Cloud computing platforms were in their infancy, and building high traffic apps required economies of scale that many people didn’t have or couldn’t afford. Mobile technology was nowhere near what it is today (just imagine what happens when 5G is prevalent). How many of you have experience in all of these areas?

We all have holes in our resume, the pace of technology changes so fast and it’s impossible to be an expert in everything, so you have to pick and choose. But over time, some of your areas of expertise will become obsolete. You can ignore this for awhile before it’s damaging to your career. But if the pace of disruption is increasing (almost exponentially), obsolescence may catch up to you faster than normal. There are a lot of middle managers out there that are struggling to find their next opportunity because they’re well-versed in yesterday’s technology and methods.

Reinventing yourself

My belief is that in the next 30 years or so, I’m going to have to reinvent myself several times. This doesn’t have to mean completely switching industries, but the way we build software may look a lot different. The job titles that are prevalent on job boards 10 years from now might not even exist yet.

This is why I’m taking online classes on data science, why I’m excited to attend CodeMash this week, and why I’m delving more into topics like cloud architecture and containers and spending less time on learning the next JavaScript framework. Someday “everyone” might build apps in Vue instead of React, but they’ll be doing mostly the same activities and building the same thing (maybe a little easier). But what if companies decide to spend money on data science instead of building large web applications because the benefits of data science are exponential?

The pace of our learning needs to keep up with the pace of the disruptions. I would rather be working now to catch up with the curve than to have to start from scratch. Companies need to take this seriously and find ways to help their employees (both developers and engineering leaders) stay ahead of the curve. How much time and money are you spending on learning before you’re stuck having to reinvent yourself?

If you dislike change, you’re going to dislike irrelevance even more.
– General Eric Shinseki

When it comes to managing your money, we all generally know it’s a good idea to save money, avoid debt, and live within your means.  The same concepts also apply to software development.

The goal I have for my teams is that we get to a point where we’re playing from ahead – that we’re not burdened by technical debt, we have the respect and trust of our stakeholders, things generally end up being easier than we think, we can make decisions based on what’s good long term vs. just having to get things done, and team members feel like they are set up for success.

I view this as a critical element of high performing teams.  Just like with credit card debt, you might have a really talented team that can do great things, but if you keep amassing debt and having to make short-term decisions that aren’t best in the long term, it catches up with you real quick.  I would rather be the smart investor that makes smart decisions and plays from a position of strength (your team will appreciate it too).

Technical debt

Most people would agree that personal debt is a bad thing, particularly when you’re amassing debt because you’re spending more than you’re earning.  Credit card debt typically comes with high interest rates, and so does technical debt.

Software rots, and it happens insanely fast.  How many times have you written some code and then two weeks later you want to refactor it so that it’s written in the “new better way” that you just came up with?

On most teams, technical debt is not regularly addressed, usually because nobody planned for it.  Once things get to a certain point (and it doesn’t take long to get there), rectifying the problem is such a daunting task.  It’s really hard to convince your stakeholders that you need to go spend weeks just cleaning up technical debt and not delivering functionality.  They likely assume that you’re building things in a sustainable fashion, so if you’re not, you’re selling everyone short.

We need to be proactive with technical debt.  If you’re playing from ahead, you can afford to set aside a small percentage of your capacity for addressing technical debt.  When you encounter technical debt while you’re working on features, you can afford to take the time to fix it as you go. Now you’re in position to continue to set your team up for future success, without to having to stop everything to do it.

Here’s how I sell technical debt maintenance — our stakeholders expect that we can turn things around quickly and provide a certain amount of value, and in order to continue to deliver quickly and predictably, we need to keep the codebase in a state that allows us to do that.  Help your stakeholders understand why they should care about technical debt and they will thank you for addressing it.

Realistic planning

Look, we all want to get a lot of work done and make the people we work for happy, and I have yet to meet a stakeholder that didn’t have a really long wish list of things they wanted done.  But when we over-promise, we put the team in a situation where they have to prioritize short-term decisions over the long-term health of the codebase.

We have to be willing to push back against things that will overload our timelines.  I don’t fault anyone for asking for us to do more, but we need to protect our teams from getting overloaded and getting into situations where they aren’t able to continue to deliver in the long term.

Software teams get to define what is “normal”.  If your “normal” involves constant crunch time, that happened because the team leaders let that happen.  Everyone will come to some shared understanding of what the limits of the team’s capacity are, and there is always a limit.  The limit is always reached when the team leaders say no.  So why do we let things get so overloaded before we say no?

My reputation as a leader is on the line every day with my team members, my stakeholders, and my superiors.  The challenge is how to provide as much value as possible while not subjecting the team to death marches and long periods of “crunch time”.  And if you believe that “crunch time” is good because it keeps the team focused, just wait until you have to pay for all of the short-term decisions that they’re forced to make.

Expecting the unexpected

Unexpected things happen.  Sometimes things take longer than expected.  Sometimes your stakeholders miss critical functionality that they need you to build now.  Sometimes team members leave and you have to replace them (and onboard someone new).  On our team, we had two developers out two months each on long term leave.  You can make excuses and say you didn’t plan for all of these things to happen, but the fact is that you can plan for the unexpected.  The trick is figuring out how much slack to leave in the schedule for the unexpected.

I personally got burned by this one.  I’m not sure what amount of slack I need to leave in the schedule yet, but many teams plan for 0% of unexpected, which I can promise you will be wrong. 

Never put yourself in a spot where you will be totally screwed if someone on your team leaves.  You can track how much production support you typically get.  If you regularly get unexpected requests that you can’t get out of, plan for that as well.  If things go better than expected, I’m sure you can find something to work on.

Getting back on track

If you’re playing from behind, the best thing you can do is acknowledge the situation.  Let your team know that you realize that you’re having to make short-term decisions that are less than ideal.  Let your stakeholders know why you aren’t able be as productive as you would like.  But more importantly, have a plan for how you’re going to make this better and what it’s going to take to start playing from ahead once again.

Next level success

When you’re playing from ahead, your stakeholders will be much happier, your codebases will be much cleaner, and your team will be much happier.  You’ll be able to take advantage of opportunities that might come up where you can provide extra value or pursue innovative solutions.  It also frees up your team to think creatively instead of having to pour all of their energy into scrambling to meet their deadlines.

This is my goal on every team that I lead.  Not that I’ve always attained it, but when you start to see the ball rolling downhill instead of pushing it uphill, it’s an exhilarating feeling and the entire team feels it.