Stephen Nimmo

Energy Trading, Risk Management and Software Development

Category: Management

Four Keys to Flow – Creating Developer Productivity

river-89180_1280The flow state is the key to developer productivity. Getting into flow, where the developer seems to enter a state of hyper productivity by removing context switching related to distractions, has been determined to be one of the best ways to achieve high throughput from development team. To create a flow state, the environment in which the developer is working needs to be clear of distractions allowing them to focus on the task at hand, and get really engulfed in the now of the problem. Several studies have shown the costs of context switching to be huge, sometimes resulting in delays of 15-45 minutes while the person can get back “into” a problem or algorithm they were working on after an interruption.

Here are four ways your organization can create greater opportunities for your employees to enter into a state of flow.

  • Remove Electronic Stimulus – if flow is the hero of the story on developer productivity, then the bad guy has to be email. Most email is worthless and a drain on time, but even worse is the perception that email needs a timely response. Change your organizational attitude towards email by eliminating the perceived requirement of being available to email 24×7. Instead, allow your developers to turn off that email and check it at regular intervals instead, perhaps for 15 minutes in the morning, before you leave and perhaps once after lunch. If your employees are sending or reading more than 45 minutes of email every day, it’s too much. Also turn off the IM – make yourself Do Not Disturb. If they need you for a priority 1 type emergency, they will call your cell phone. Don’t worry.
  • Create No Meeting Blocks – the organization needs to create windows of long, uninterrupted time for the developers to get into flow. Back to back meetings with one hour windows between is almost worse than all day meetings on developer productivity, because the code resulting from those 45 minute blips will be disjointed and result in a ton of rework. Block out time for the developers, start with Mon-Wed-Fri between 9-2 and see what happens to your productivity. Oh, and no meetings on Friday.
  • Make Flow Visible to Others – back when everyone had an office, if you needed to get into flow, you just shut your door. With open offices and floor plans, it’s now difficult to shut yourself off from interruptions. The organization needs to setup some identifiers to allow potential interrupters the ability to stop themselves. The headphone rule is a good one, where if someone has headphones in, do not disturb them. Some workplaces have flags at their desk to tell everyone if they are open to interruptions. Whatever methods you choose, make them visible and well known to all so instead of breaking someone’s flow, they can read your email later.
  • Empower Pushback – for all but the highest priority items, such as outages, the team members should be able to rebuff interruptions. Let’s be honest, some players in your office don’t feel like the rules apply to them and will often break protocol at any time to fit their needs. The organization needs to empower the developers to push back. A polite response of “I’m in flow, please send me an email” to these interruptions gives the developer the ability to get back to the task without issue. But persistent violators will need to be handled by management and the organization must empower their managers to call out violators and get them to respect the rules.

The suggestions above are a few ways to quickly gain productivity in your workplace but implementing these are sometimes difficult to manage, as non-IT folks who use email as their work queues and are used to getting immediate responses may revolt at the perceived delays in their own productivity. This organizational behavior change must be something that not only comes from the top down, but is also something needing respect from every level in the organization. If the VP decides to break protocols, it’s difficult to enforce it on the directors and so on. So remember, unless it’s an outage send an email and they will get back to you after they are finished. I promise.

Technical Debt Snowball

Most Americans are familiar with a personal finance strategy colloquially known as “Dave Ramsey“. The course is actually called My Total Money Makeover and is a regimented and proven strategy for getting your debt under control and moving into a more financially sound position. The foundation of the course relates directly to a single set of tactics collectively referred to as the “Debt Snowball”. Using this tactic, people line up all their outstanding debts from smallest to largest and begin to pay extra money into the smallest debt first, while paying only the absolute minimum to all the other debts. Once the smallest debt is paid, then take the amount you were paying on the first debt, add it to the minimum amount on the second debt and start paying on the second debt. Like a snowball rolling down the hill, with each debt conquered the total payment grows bigger and gives an ever increasing leverage to knock out the larger debts. There is also a huge psychological boost for the average person by starting with the small debts first in creating momentum and quick wins, which are imperative for those who have trouble forming habits without positive feedback. From a purely financial sense, it’s actually better to pay off the highest interest debt first, but the differences in percentages may not justify the loss of momentum and positive feedback needed for the average person struggling with debt issues to be successful.

Surprisingly, when you start the process, there is a first step that doesn’t sound intuitive, but is absolutely imperative for those people living in a situation of crippling debt. The first step is the emergency fund. Before any debt is paid, the individual is highly encouraged to create an emergency fund of $1000 to create a cushion for any unexpected debts or issues that may arise over the course of your journey. The reasoning is this: People living under the immense pressure of not knowing if they will be able to pay their electric bills or if a car repair might cause them to lose their job are simply unable to make good decisions. The pressure is so intense at that point, that most people’s ability to make strategic decisions get short circuited and they only think about how to relieve the pressure, even temporarily and by any means necessary. In addition, people living in such conditions have a strong tendency to want to escape the pressure in other ways, and the escapes tend to revolve around more bad money decisions, such as impulse purchases to make them happy or throwing money at guilty pleasures like food or drink. The first step of Dave Ramsey is to relieve this pressure and create a space for strategic thinking.

In any business with large IT operations, there is a very real concept of technical debt where the organization is making technical decisions in the present that may require some level of effort in the future to “correct” the decision. From an enterprise sense, even some of the major product decisions are creating technical debt they may not even be aware of. To use an example, if you choose to use Microsoft Outlook for your company’s email, the decision is creating technical debt related to upgrade paths – the organization will eventually be forced to upgrade or change platforms. For custom application development, technical debt has a direct correlation to certain decisions such as choosing not to automate your regression testing or not creating unit tests. These decisions could be due to budget constraints and simply not having enough staff to perform the activities, but you’ll end up paying for it later in either time or lost productivity.

When your IT organization creates too much technical debt, either through their own lack of discipline or through direct pressures placed on them by decision makers, it will eventually reach a point of becoming crippled operationally. The staff gets so bogged down with production bugs and performing low value activities such as manually testing code, no new features or business can happen. The IT staff start living with the illusion of choice – do we spend out time today getting our CRM back up so we can conduct normal business, or do we work on the new website designed to bring in new customers? There is no choice there. When things get this bad, there will usually be some sort of change that will allow for some movement to be made on paying down the debt. This could come in the form of cancelled projects, contractors for hired muscle or even outsourcing an entire system replatforming if the debt is too large (i.e. IT bankruptcy).

When the company becomes aware of the issues, the ensuing prioritization discussions begin. How do we pay down our debt? Some may suggest using a purely financial model – eschewing the aspects of momentum for prioritizing work for the issues having the largest impact. However, using this type of prioritization means the organization will miss out on a key feature to the snowball – it needs to learn how to pay off technical debt and not create new debt. Taking on a huge new project in an environment of already crippling technical debt pushes off the much needed positive feedback needed to reinforce what is being done is good for the company. After six months, the key stakeholders may forget about why it’s important and will refocus efforts on daily firefighting. By prioritizing some smaller and easier automation projects, monentum and feedback loops can be created, resulting in a better chance of long term success incorporating good software delivery practices as a part of normal culture.

The organization should start the attack on technical debt using continuous delivery concepts. First, it needs to create that emergency fund. For the most part, the quickest way to get your organization out of panic mode (i.e. emergency production support) is through the creation of automated regression testing. Being able to fix bugs and not introduce new bugs is the debt snowball equivalent of knowing your lights won’t be turned off. It creates a cushion of confidence that developers can fix current production issues without introducing new debt. This is also the start of the technical debt snowball’s momentum, as the IT staff can begin to start fixing actual bugs using the time they were previously spending identifying and testing old support issues. Every time a new automated test that saves 5 minutes a day is created, 6 days of slack is created. Think about 100 new automated regression tests, each saving 5 minutes a day and you’ll see the snowball. Automated regression testing should always be the starting point for any debt paydowns – even if you are replatforming! Once the automated regression snowball starts knocking out those small debts, then the time saved can be used for tackling some of the larger pieces of automation such as creating automated build and deployment scripts. This will create the cushion needed for your ops team to start monitoring the services in a more proactive manner, leading to additional uptime as the ops folks can tackle issues before they become outages.

The cushion created by automation can then create opportunity for the organization to tackle larger strategic issues. To be clear, executives don’t want to talk about a 5 year vision when core systems have been down three times this week. But once the snowball starts rolling, it’s hard to stop it. The momentum created from continuous delivery creates a fervor from the business to create more opportunities for optimization of processes, which will then allow the IT staff to work on projects with actual business value. Everyone in the organization begins to recognize the need to pay down debt regularly and give the developers and operations more budgeted time to perform those activities needed to reduce technical debt, such as writing automated tests and refactoring bad code. If you are current working in a environment where the daily norm is daily dire drills and emergency releases, it can be excruciating and ultimately the employers will start losing key staff. Ultimately, taking care of technical debt is something that will be addressed. The only question is how painful it’s going to be.

Value Based Feature Prioritization

When someone asks me what I do, my answer is fairly simple. I try to influence my company to do the highest value things first.

The classic product manager is tasked with deciding what features and enhancements will make the product better. There is a ton of work and time spent simply identifying features and writing descriptions of the processes providing value to your organization. The examples can get fairly complicated, mostly in describing the assumptions of the state of the systems and data prior to the start of the process, as well as documenting the alternate cases based on different workflows. These descriptions can be done in different ways depending on your management style, but most product managers write user stories, user case documents and there are plenty of product managers out there still writing requirements documents.


Writing use cases and user stories takes up about 70% of my daily time but the act of simply creating and formulating this process documentation is not where product managers provide value to the organization. A good product manager delivers the highest value features first and determining the value of features to the organization is key to delivering software and projects in a productive manner. Without some metrics around valuation of features, it’s guessing. There are numerous ways to determine feature value. Here are some of my favorites.

Operational Expense Reduction

To use a simple example, take a piece of software that requires your team of DBAs to provide ad-hoc support to the tune of about 4 hours every week. Take that cost and multiply it by 52 and you have a yearly cost (~200 hours a year at $100/hour) and a rough value, around 20k. Using a simple case like this does not do justice to the fact small software changes and process updates could reduce thousands of people’s workload by something as simple as 30 minutes a day. Take the same piece of software and add in a feature reducing the average user’s work by 30 minutes a day. Let’s say you have 1000 users. That’s a reduction of 500 hours a day! At $20/hour, the feature is potentially worth $2.5 million.

Increased Revenue

“If your software had that feature, we’d buy it”. Usually this is a statement heard in almost any sales cycle. Sometimes it’s a ploy to start negotiations with leverage on the buyer’s side, especially if there are other products on the market with the desired feature. There are other times when the statement is used to begin the judgement on the availability of the software provider to respond to your organization’s needs. Quite frankly, there is a reason for the stereotype of having a highly responsive organization who disappears after the check clears and watching the organizational behavior prior to the sale is smart for any buyer. Finally, there is an actual legitimate request for the feature.

How do you value a proposed feature for increasing revenue? Obviously, your company has some metrics around profitability of similar clients or past sales, so depending on the size of the sale (one license versus 1,000 licenses), then the feature value could be enough to push the priority up for this one sale to close. Most of the time, that’s not the case because it’s not only about the feature to the single potential client, but the thousands of other clients in your target segment. If a feature could add 200 new clients, then do the math on profitability per new client to determine value.

However, be wary of two additional realities of using this as a valuation method. First, you must also take a look on how the feature may or may not be accepted by your existing client base. Is this feature, which might be a significant enhancement to an existing workflow, going to cause waves with your existing users? It’s always cheaper to keep an existing client than it is to bring on a new one so if there is a potential for any lost clients, the costs of the risk must be valued into the feature. Secondly, how you ever heard a salesperson say a new feature or enhancement wouldn’t boost sales? Neither have I. Make sure to put actual metrics or past performance in the decision, not the gut feel of your sales force.

Reduced Organizational Risk

Every day your company is at risk. Your contractual obligations and regulatory requirements, depending on the type of your company, could put your daily risk into the millions of dollars. Some of the energy regulatory bodies, such as FERC and the CFTC, can put some serious weight on your company if you do not follow their rules, especially if your compliance gap is around worker safety.

Product features in your backlog could be tied directly to one of these potential risks. When I worked for Enron in their natural gas transportation division, we were engaged in the full rewrite of their entire contacts and capacity release systems for three big pipelines. This project was years in the making and while this project was happening, the maintenance on the existing system had to be brought down to bare bones. Along the way, there are regulatory changes which require system changes, whether it’s operational changes or something as simple as changing the way volumes are aggregated, those mandates have penalties as well as due dates. While doing the system rewrite, these changes were introduced as features and while some of the due dates were given extensions, eventually the time came for us to get the project into production or face fines. Needless to say, those were some long months for us but we were successful on the delivery.

When you are trying to value features associated with risks, there are two ways you can do it. First, there is simple example of a feature that is absolutely required by a certain date and if it’s not there, you will get fined. The potential fine in question is only the baseline of the actual value. There are certain cases where the increased scrutiny into the organization will cost you even more. When there are data requests and audits, the time and expense associated with them can be very painful, not to mention the costs associated with the negative publicity. No company wants to be associated with non-compliance because your clients will view these gaps as potential hazards to their operations.

The really difficult area for valuation of features for reducing risk exposure comes from development of features replacing existing, brittle processes. To use an example from energy trading, if you are running your end of day calculations to determine the cash needed for margin calls, and that process can sometimes “break”, then the number may sometimes be wrong but not cause your organization any harm. For example, if it calculates you need 100k but you only need 80k, then the only value lost is opportunity costs for the extra 20k in cash which could be used in other parts of the organization as working capital. But let’s flip those numbers around and the story changes. Falling 20k short on a margin call could spell disaster for companies, causing not only regulatory scrutiny but could result in a full liquidation of position at a huge loss. To create valuations for these features, the calculation is based on real options analysis, taking the probabilities of these complliance events happening and multiplying by the potential losses.

Technical Debt

Every project accumulates technical debt along the way as decisions are made regarding the architecture of a software project. Some of the decisions creating this debt are caused by external pressures to deliver at all costs, causing developers to hack together solutions quickly with the promise of being able to go back and refactor out the bad code (which rarely happens). In addition, there is also technical debt accumulated as the product requirements change. The ORM decision made during the first month of a project could be a proverbial anvil around the neck of a development team three years later. These decisions are made based on the best available data and sometimes the data is incomplete.


Technical debt has very distinct impacts on the product, specifically inhibiting the ability to deliver value quickly. Adding a feature in one stack could take a day, but in other stacks could create a week long regression requirement and cost ten times as much. If there are pure technological debt issues existing, they need to be put on the backlog and prioritized. Much as when a company does a stock buyback because they have capital on hand and no projects on the books with a good ROI, these technological debt backlog items can (and quite often do) become budget killers adding 25% to the costs, sometimes much more, and when there is nothing else in the backlog more valuable than to refactor out this debt, then pull the trigger and get it done. Refactoring out bad code is like taking the extra minute to put on a pair of shoes before running a marathon.

In conclusion, a good product manager isn’t only someone who can write good use cases. It’s someone who can make good decisions and provide great analysis on where the product should focus. These simple feature decisions could change the bottom line and something as subtle as prioritizing one feature over another could make or break your organization. As always, a product manager is only as good as the support they have from management. Make sure to empower your managers to make decisions, but also don’t be afraid to hold them accountable as to why thing were prioritized the way they were.

Define Your World

I recently finished reading The Dip, a short book by Seth Godin which does a great job explaining how to be successful in the projects in which you choose to engage. The concept is simple.


  1. Anything that you choose to do (project, work, hobby, etc) has a dip, which is the amount of time and effort required to get between the excitement and enthusiasm involved in a new endeavor and the desired end result – also known as the hump.
  2. Everything has a dip but dips are different. Learning to say hello in 5 languages has a dip of maybe an hour or two. Learning to speak 5 languages fluently has a dip of years, possibly decades.
  3. For those things you are seriously interested in engaging in (not hobbies), such as starting a new company or writing a book, you need to be able to prepare for the dip, recognize it when it happens and work through it by either incorporating strategies to be productive through it or shorten it.
  4. If you aren’t willing to go through what’s required to get through the dip, you shouldn’t even bother. Quit now and save yourself the time and effort to focus on something you are willing to get to through the dip on.
  5. You should also strive to be the best in the world in what you do.

Best in the world? Yep. But Seth throws a little curve ball as his definition of the world comes with a big asterisk. Best in the “world” is being best in the world in which you define it. Looking at it from a consumer, let’s say you want a graphic artist to do some logo work for you. You want the best (who doesn’t, amirite?). But there are several problems with attaining the best. The best is usually already busy with other work they find more interesting (availability), their prices are out of your range (accessibility) and some of them you might not even know about. So you can’t have the best, but you can have the best based on the available graphic artists who are available and willing to take what you are willing to pay. These two aspects just cut your pool down about 95% with two simple characteristics.

But using Seth’s logic, this is what you should be focusing on – being the best of the world of the graphic artists who are freelancers, are willing to do things for less than $100/hr and have bandwidth. All of the sudden, the world as you know it becomes much clearer and even attainable. Now, you can take this world construction down to such a sganular level that it becomes absurd. I am the best blogger in the world named Stephen, using WordPress, who is 6’1″, etc. This doesn’t really do much for me. However, being the best blogger in the world doesn’t give me much value either. Instead, I pick a middle ground. I want to be the best software development and product management blogger in the Houston area. While that pool is still pretty deep, it is also something I can strive towards and it’s an attainable target, if I can get past the dip. My dip involves refining my writing style and increasing the value of my offerings. These are very tough things to work on and require some pretty serious commitments. Your world may change as you develop and attain new skillsets or experience. A software developer’s world may go through several phases.

The best at documentation out of the 3 junior developers on the team.

The best at refactoring the persistence layer on the team.

The best developer on the team.

The best developer in my section.

The best developer in my company.


If you have some spare hours this weekend, grab a copy of the book and give it a read, especially if you are like me and have many more projects that you start but don’t finish. Reading the book and understanding the concept isn’t hard. Defining your world is the real dip. Start small. Dream big.

© 2017 Stephen Nimmo

Theme by Anders NorenUp ↑