Entrepreneurial Thinking

I recently gave a talk to the Cape Cod Young Professionals’ (CCYP) Mentor Exchange on Entrepreneurial Thinking and Thinking Like an Owner. I use the phrase “thinking like an owner” when referring to employees who have a strong work ethic and go the extra mile. There are a number of characteristics I outlined with the group of mentors/mentees who have been participating in the program. The first was debunking the myth that being a business owner is not really working for yourself per se. When you are an employee you have a pretty clear idea of who you work for. When you’re a business owner, you work for everyone; customers, employees, shareholders, board of directors, investors, etc. The other characteristic of thinking like an owner is doing tasks that technically don’t appear within your job description. It could be as simple as taking out theshutterstock_144471493 trash, answering the phone, or greeting a customer. It could also be taking on a special project, staying a little later/coming in a bit earlier, and showing the owner you care about their business to do what it takes. These little things go a long way toward ingratiating yourself with a business owner and nothing drives them crazier than when an employee claims “that’s not my job” if asked to do an extra task.

During the next part of the talk, I focused on concepts and characteristics which drive the entrepreneurial mindset. Four I can especially relate to and defend.
1. Know your customer: This is the most important part of being an entrepreneur. Knowing what your customer looks like, thinks about, and wants. Specifically, what problems you can solve for them, what pains they have, and what gains or benefits they are looking for when you perform a job for them.
2. Attitude is everything: I explained how a positive, welcoming, and optimistic attitude will help you succeed as an entrepreneur. It is amazing how well your customers, employees, and vendors respond when you treat them with a positive attitude.
3. Don’t fall in love with your concept: This seems like a simple statement, but entrepreneurs often become myopic and defensive about their concepts. When you get out of the building and actually talk to real customers, you may discover they may not want what you have to offer. Based on what you hear from your customers, you may need to kill it, adapt it, or pivot away from your original concept.
4. Failure is an option: True entrepreneurs embrace the concept of failing fast, knowing how to do it gracefully, and learning from the experience.

I have learned and adapted many of these four concepts from the great work done by Eric Reiss (Lean Startup), Steve Blank (Startup Owner’s Manual), and Alex Osterwaller (Business Model Generation and Value Proposition Design).

How will you differentiate yourself ? – Getting ahead of the competition in the life insurance industry


At NeuEon, our success has been built on our deep domain expertise and our ability to become trusted advisors for our clients. One industry we have the pleasure of working in, is Life Insurance.  Some of the brightest minds in this business ask us,  “What are my competitors doing to stay ahead of everyone else in the market place?”. Most firms want to focus on accelerating the introduction of new products, riders, and features to increase market share and new premium revenue.

Our clients often lament on their inability to introduce innovative products and offerings to the market in a timely fashion.  The cause for delays are always related to market focus, product launch, project implementations, and resource issues. In general, we find that client resources are continually being dragged down in the day-to-day tactical fire fighting which does not allow them to look strategically across the enterprise to increase efficiencies.

Over the next few weeks we will discuss the benefits of stepping back and assessing the overall health of your business technology vision, including:

  • Market segmentation – The traditional demographic of your client base will be changing as younger generations entering the market with different needs and priorities.
  • Process Standardization - Effective project and cost management can be achieved by utilizing “playbooks” and standards for repeated periodic events such as changes to investment options, forms, and new rider launches.
  • Straight Through Processing - Service is a significant differentiator, it must be easy to do business with a firm from a distribution, policy issuance, and in-force processing perspective.
  • Data Management – Effective data management will enable leadership to make smart business decisions based on consistent data.  It also provides consistency to the end client.
  • Platform Rationalization – Companies have created more and more complexity in their technology stack through M&A activity, as well as, a lack of sun-setting legacy platforms as new technologies are introduced.

These are complex topics spanning the front, middle, and back offices of an insurance company. This series will provide an appreciation for the technical and business strategies we have helped our clients with in order to optimize their organizations for the future.

Are you managing your technical debt?

shutterstock_147127772All software organizations accrue technical debt. Some, our actions add to our debt. Every time we copy and paste a block of code and make one little change, or use a library for something other than its intended purpose, we ring up another small amount of technical debt. Other times, the debt accrues through inaction. Ignoring compiler warnings, failing to document code, or sticking with a technology platform longer than we should have can all make a codebase more difficult to live with. In all these cases, we end up with something that isn’t as good as we know it could be.

We usually create technical debt for the best of reasons. Most often, we’re in a rush to make a deadline. It’s easy to tell ourselves: We got it working, even if it is a little ugly. We need to move on to the next item. We’ll come back and clean that up later. In many organizations, “later” never comes. Once the code is in production and working, it’s more difficult to justify expending effort to change it. If you have poor regression test coverage, you might even be scared to change it. Over time, your state-of-the art code turns into a confusing jumble of workarounds. Your team velocity declines, and morale goes with it. Your developers know they could make things better, if they only had the time…

The best way of dealing with that situation is to avoid it in the first place. There are three main things you should do, as a software development manager and leader, to keep your technical debt under control:

1. Set standards that reduce opportunities for technical debt. Having a strong set of standards for code formatting, use of frameworks and third-party libraries, and unit test coverage will help the team maintain consistency and good structure in the code. All team members should be empowered to hold each other accountable to these standards, but as the manager, you will need to know what “good” looks like and take the lead in establishing the standards if they’re not in place. Some team members may grumble, but eventually most will see the utility of adhering to these standards.

2. Describe your technical debt. At some point, the team will decide that the best course of action is to accrue a debt in order to reach a goal. When that happens, you should add a corrective action to your backlog. The only way the team will remember to go back and address these things is to write them down. Having technical debt backlog items also allows you to estimate the amount of time and effort it will take your team to address the debt. You may want to create a backlog item type specifically for technical debt, to distinguish it from the typical user stories and bugs.

3. Prioritize technical debt items along with other backlog items. Once you’ve described your debts, you’ll only pay them off if you give the team time to work on them. The best way to do that is to include technical debt items with your other backlog items, and prioritize them together. If you’re following a Scrum process, your team may need to educate the product owner on the need for these items. Your developers must be prepared to advocate for their items in terms of the business value they will deliver. If there’s no business impact (perhaps increased quality or development efficiency), why is the item in the backlog?

Doing these three things will put you in control of your technical debt. You should not attempt to eliminate all debts, but you should make sure you don’t acquire more debt than your team can handle over the long term. What if you’re inherited a legacy code base that seems to be nothing but unaddressed technical debt? That’s a difficult situation, but one that most of us have seen before. We’ll tackle that in a future post.

‘FREAK’ flaw undermines security for Apple and Google users, researchers discover – The Washington Post

Technology companies are scrambling to fix a major security flaw that for more than a decade left users of Apple and Google devices vulnerable to hacking when they visited millions of supposedly secure Web sites, including Whitehouse.gov, NSA.gov and FBI.gov.

This appears to be a flaw you should know about.  It affects Apple and Android devices as well as Web browsers but a fix is in the works. For more information see:

‘FREAK’ flaw undermines security for Apple and Google users, researchers discover – The Washington Post.

Lessons from a struggling software project – Step 1: Identify the failure scenario

Struggling ProjectsIn our Fractional CTO™ practice we often help distressed software development teams in the middle of a struggling project, or right after one has failed. Regardless of the size of the organization or project, the failures are usually caused by tensions between the definition of the end result and the process by which the team attempts to accomplish it.

In this series we will explore our approach to identifying and addressing project failures in the hopes of enabling you to capitalize on our lessons learned. We break the process into four steps; identify the failure scenario, assess the indicators of project risk, identify the root causes, and then formulate a remedy.

Step 1: Identify the failure scenario

Every new situation requires us to first identify the type of project “failure” the client perceives they are dealing with. We want to identify themes in order to build team consensus and understanding of the issues from a strategic point of view. Later we will create an action plan to resolve the issues. Typically, project challenges fall into any of the four categories described below. If you have ever struggled with a software project these categories may sound familiar.

Financial disaster

There are many reasons why a project may feel like it is sucking money. So when it becomes clear management views the project as an endless stream of unplanned costs we focus on that. This could be a lack of cost controls, poor project management or software quality and practices, or a variety of other challenges in the SDLC that we will try to identify in a later stage of investigation. Usually this can lead to other serious problems and significantly erode trust and communication and force bad choices. For instance, you don’t want to throw good money after bad but replacing the team or changing the project goals may make things worse. It’s important to get to the root of the problem quickly before this high burn rate leaves you with no good options. When this happens project termination, or abandonment is often the result.

Unending scope creep

The project requirements continually change resulting in a seemingly never-ending project with more and more features but no sense of completion. In some cases there may be no releases, just a steady stream of new requirements. A variation on this is a sense that the software isn’t “perfect” so it is either never released or the release is never considered worthy due to constant tweaking. This could be due to poor quality in any stage of the Software Development Life Cycle (SDLC) combined with unrealistic expectations. There is simply no clear strategy for calling the project “done”.

Over the course of these projects Management will often ask “Why can’t we ever ship anything?” or “This seems simple, why can’t we finish it?” It is common to hear the development team in these situations complain that, “Every time we show Management/The Customer our progress they change what they want.”

The result will often be that Management becomes frustrated with the lack of a released product and out of control costs. Meanwhile this endless drip of requirements can lead to low development team morale since they want to feel accomplished. What’s worse, this deterioration of morale can lead to a lack of project commitment since the team will feel like they can’t finish anything and that feeling slowly becomes the accepted cultural norm.

Bitter endings

The team finally hits their milestones but the project is not viewed as worthwhile upon completion. The perception may be the overall costs were too high, “nobody” is finding the new features helpful, it’s possible the original intent and need has been forgotten. Even worse, the resources, who are now burned out, could have been better utilized. As technical leaders ourselves it hurts to recognize the tremendous amount of energy and creativity that went into a project which when finally completed no longer represents core business value. We find this more often in non-agile projects, however even projects utilizing tight iterations can suffer from this disconnect when there is a lack of real product ownership and an uncommitted team that doesn’t challenge weak requirements or focus on consistently delivering value.


When a project fails it may end up getting turned off, resources reallocated or let go. For a small company this could be the end. For a larger company it could be the end of a strategic vision or it could be wasted money followed by a reboot with a different team or approach. Abandonment is the result of not identifying the signs of a project at risk and taking action soon enough. The mistake many companies make with this type of result is they don’t learn enough from it. Taking the time to really do a detailed and constructive analysis of what happened can be invaluable, in fact, in the long run it could be more valuable than the promise of the original project. If an organization learns sufficient lessons from their mistakes they can become a stronger and more effective organization. So while this may be the worst of all outcomes for a project it doesn’t have to be a complete waste for the company.

Project ManagementThere are of course many types of failures but these four general scenarios cover the majority of situations we help to unwind and improve. They are also in the back of our mind whenever we are helping to launch new project initiatives as serious risks to avoid. Understanding where the project stands and having the team come to consensus is the first step in fixing the problem or avoiding it in the future. In the next installment we will examine some of the underlying indicators that help us clue in where the issues are percolating so we can later hone in and address them. These key issues are also important areas for new teams to learn to avoid and address quickly so their project doesn’t end up in one of the failure scenarios.

If you have any war stories and observations on this topic we would love to hear from you. By sharing our experience we can all improve our process and deliver high-quality solutions.


Commitment to Process – Key Quality of Successful Development Teams

CommitmentOne of the benefits of the work we do at NeuEon is that we have the opportunity to work alongside some very talented developers.  Yet, more often than not, we find that one of the reasons most products fail and why most development teams are not successful in meeting their objectives has nothing to do with their ability to write code. One of the reasons most teams fail is because they do not follow a disciplined process for building production quality software. The actual process a team subscribes to is less important than the fact that they have one. You could argue that one methodology is more effective than another.  We happen to like Scrum, but there are others that are just as good.

Once the team determines the methodology will follow, it is imperative that they commit to it and hold each other accountable to it.  Let’s use the Scrum process as an example.  The knock on Scrum is that it is too rigid.  The reality is that Scrum has very few rules, however the few that do exist must be followed with the utmost discipline or else the process and the team will likely fail.  Scrum calls for a select number of meetings that happen in regular intervals.  These events include:

  • Sprint Planning Session – occurs at the start of each development sprint to allow the Product Owner to communicate the priority of the stories that the development team need to complete during the sprint.
  • Daily Standup – occurs every day for upto 15 minutes in which all members of the development team answer three very specific questions – 1.) What did I complete yesterday; 2.) What do I plan on working on today; 3.) What roadblocks do I have that I need help removing
  • Sprint Review – occurs at the end of the development sprint.  The development team demonstrates the work that was completed in order to give the Product Owner and stakeholders the opportunity to sign off that work was completed as specified.
  • Sprint Retrospective – occurs immediately following the Sprint Review to allow the development team to discuss how the team can improve.  During the retrospective teams ask 1.) What did we do well – what should we do more of?;  2.) What didn’t we do well – what should we do less of?

There are obviously many other principals of the Scrum development methodology such as story estimation, acceptance criteria, backlog grooming, etc., however for the purposes of this article we are going to focus on the four mentioned above.

The interval in which these meetings occur may vary from project to project depending on the length of your sprint.  What should not change is when they take place.  The Sprint Planning Session takes place on the first day of the sprint, and the Sprint Review and Retrospective occur on the last day of the sprint.  These meetings must be scheduled as recurring events on the team’s calendars.  Successful teams hold each other accountable for attending every meeting and coming prepared.

During the course of every development sprint emergencies occur, and priorities are challenged constantly.  What must stay constant however is the commitment to the process.  Early in the process it may feel as if the “overhead” of the process is getting in the way of completing tasks, but the time spent is essential for long-term efficiencies.  A common statement we hear is, “I can’t make it to the planning session because I have to finish a deliverable for this afternoon.”  This is unacceptable.  Good teams create a culture of that puts the process as a top priority.  It is the responsibility of each individual to plan their availability and forecast deliverables around the commitments of the process.

When you join a Scrum team you commit to the team and the process.  The meetings are critical to the success of the project and in start-ups, the business.  Early in our involvement with new teams, we ask them to look around the room and count up the hourly rate of each team member to put a dollar amount to the meeting.  This inevitably gets the attention of  the business owner when they view it from a financial perspective.  In many cases these meetings cost the company thousands of dollars.  When individuals and the team do not approach these meetings with the necessary commitment and diligence, it has a negative impact on the business not only on productivity, but financially as well.

On Being Remote and Not

We subscribe to many of the points outlined in “Remote: Office Not Required” by Jason Fried and David Heinemeier Hansson.  Especially the concept of getting together in person from time to time.

Remote: Office Not Required

Remote: Office Not Required

In January we had the chance to meet for our annual company meeting. It was a chance to have team members that have only met via Google Hangouts and GotoMeeting to meet in person. Our annual gatherings tend to be set up similar to a scrum planning day. There’s a bit of retrospective about the year that just passed, analyze what works and doesn’t work and review the results that we have achieved. The other half of the meeting is dedicated to planning for the upcoming year in which we look at goals and objectives and agree on what we’re committing to as a team. We also review any changes in our services as well as internal operational items like employee benefits. This is a great time to get to know each other and share a meal or two, and this year was no exception. These annual events have been so successful that we are exploring other ways to get together more frequently throughout the year.

In addition to our company-wide gathering, our leadership team took the opportunity to do our quarterly off-site planning session this past weekend. This time we were fortunate to be in Lake Placid where the weather was conducive to both outdoor activities and getting some work done. We set a theme or topic for the weekend that we want to tackle and discuss in detail – this weekend was all about marketing. This served as the topic of conversation throughout the weekend – as well as in the car and even on the ski lift.

In the past few weeks, it has become even more compelling to be a 100% remote-only company. Those of us in the Northeast of the United States and more specifically in Eastern Massachusetts have been subject to a crippling amount of snowfall. This extreme weather has made virtual meeting technologies a critical investment for us and reinforced our belief in our “Remote: Office Not Required” philosophy.


Happy Holidays

We appreciate your business!

We’ve been getting lots of calls, emails and text messages about this commercial…. yes it is the leadership team at NeuEon (@ 12 seconds in).

Thanks to our friends at VistaPrint for running it again this year, Happy Holidays!


.NET goes open source – what does it mean for you?

You may have been a little distracted yesterday by the historic landing of Philae on Comet 67P, so don’t be too hard on yourself if you missed Microsoft’s announcement that it’s open-sourcing the .NET stack and making available a free, relatively-full-featured version of Visual Studio. And it’s true; the .Net Foundation Github page now features links to repos for .NET Core 5, ASP.NET 5, the Azure SDK, and several other projects. You can also now download Visual Studio 2013 Community Edition, which has many of the features of Visual Studio Professional.

I’ll add my voice to the crowd shouting “It’s about time you did that!” A free, non-crippled IDE removes a major barrier to entry for use of Azure services and Visual Studio Online. Now that the full tool pipeline is available at reasonable cost, Azure becomes an option for a broader audience, especially for open-source development. However, for many existing Microsoft development teams, Community probably doesn’t provide much of a benefit. Some teams might be able to do some more of your cross-plaftorm mobile development in Visual Studio, but the license terms for Community restrict its use in for-profit endeavors. This demonstrates that Microsoft is not yet ready to walk away from their “developers as profit center” mindset, and will continue to limit Microsoft’s ability to compete with other platforms.

Cross-platform .NET could make Microsoft more of a presence in cloud services, but that’s more potential than reality at this point. I appreciate the tacit admission that Windows can’t compete with Linux on any non-desktop platform, but the tools to actually build and run the .NET CLI on a non-Windows platform don’t yet exist. Once they do, they have the potential to reduce infrastructure costs for any .NET-based development team. Windows-only organizations will have to adapt to a heterogenous environment to take advantage of those savings, and that will be a slow process.

In summary, if you’re trying to decide whether to go .NET or not for a project that will launch in the next six months, the announcement probably doesn’t influence your decision much. Open-source projects now have access to a free-as-in-beer, capable version of Visual Studio, but you will likely still need one of the paid versions in order to do commercial development. You’ll also need to deploy your .NET code on Windows for the foreseeable future, unless Mono can run your project and you’re willing to give it a try. And the terms of the rest of the tool chain for web apps (TFS, IIS and SQL Server) haven’t changed. .NET is still a hard sell for teams that don’t have an existing Microsoft investment.


A great day and a great cause

We were proud to sponsor this year’s Walk to Defeat ALS event in Boston.  We had a fantastic team of walkers and raised $13,125, the highest team amount raised that day.   The overall event raised over $400K!

Thanks to everyone involved.

2014 ALS Walk Boston-9081