About Scaled Software Engineering

​Let's talk about who I am and my background first. My name is Jim Olsen, and I have been working in the commercial software engineering business my entire career in a variety of industries including the Airline industry, Healthcare, Business Productivity Applications, and Integrated Hardware and software systems. I have led teams as large as 1500 people at companies like Dell, Sabre, Novell, CHG Healthcare and WellSky. I have been a Chief Technology Officer, Executive Vice President, Senior Vice President and Vice President of Software engineering. The teams I have managed were made up of all the disciplines needed to build, test, and deliver optimized enterprise software, such as Software Engineers, Test Engineers, Dev Ops and SRE, Program Managers, Agile Coaches, Scrum Masters, Data Analytics experts , and Software Architects. I am a solutions oriented person that wants to make sure we understand the "real" problem, and then work to solve those problems. Over the years, I have discovered challenges that make developing and optimizing the software development process more complicated as technologies change, code bases get older, infrastructure becomes more complicated, and the company scaled its revenue and customer base. Many engineers and engineering leaders find it hard to adjust as they become part of the more complex environments they are now working in. This training provided by Scaled Software Engineering will help overcome many of the challenges and obstacles engineers and engineering leaders face in their efforts to transition, adapt, grow and scale their engineering organization.

 

In the process of managing the changes required to optimize and scale, I have learned very critical things about the product life cycle and the development process that drive the success of software teams and drive customer satisfaction. A few of these concepts tend to go against the normative grain currently working in the software world today, along with items that reinforce great things that continue to happen in our field. As I have implemented many of these concepts in a number of companies over the years, I decided that I should put it down in writing and work with others to propagate these learnings. Here are just a few of the questions that we can provide experienced answers to aid in scaling challenges:

​

• With all the advances in hardware capacity and speed, and software tools designed to increase velocity of development efforts, why is software seemingly becoming more bloated, getting buggier, and not scaling well?  A recent Stack Overflow article made these points, and I tend to agree. How can we fix it?

• How do you solve for enterprise applications that have so much legacy baggage and bad architecture, at the same time we try to integrate new technologies, upgrade our old tech stacks, leverage the Cloud, introduce AI in our development environments, all while continuing to innovate in our business?

• What is really important in scaling the 23 year old Agile philosophy and associated processes models for optimizing your teams for scaling in a contract driven world wide distributed enterprise class development effort? Hint: it's not just the Scaled Agile Framework.

• How do you decide when it is appropriate to add specific vertical roles (Test Engineer, Program Manager, etc.) and role clarity to improve efficiency and throughput as organizations optimize and scale up, instead of relying on software developers to wear all the hats needed for growth (Architect, Developer, Test Engineer, Dev Ops person, Program Manager, Product Manager, etc.)?

•  How do we assure we develop the right features and capabilities that add value for most users, and not become just a feature factory where according to Standish's recent research, 20 percent of software features are often used, while 50 percent of features are hardly ever or never used. The remaining 30 percent of features are used infrequently. However, most development teams and software organizations continue to crank out more capabilities?

• Why is it important for Test Engineering to be a "real" discipline to achieve a quality product and be a key accelerator for being able to innovate? (Hint: in many organizations poor software quality has them in an infinite "bug fix" loop robbing valuable time from innovation)

  • Why are many development teams usually unaware that their product quality is poor, but every customer seems to know?

• How do we grow and scale Software engineering leaders to optimize their teams and grow their own skills to handle the development challenges and complexities that are now occurring?

• How do we teach software leaders to better position their teams to the businesses they support to get the resources, tools, and time needed to fix and advance many of the challenges mentioned above?

 

Answers to some of these question and situations are pretty obvious, but hard to fix, and some of the answers are more complicated and nuanced, but relatively easy to fix. I am looking forward to discussing these topics on this site, as well as many others topics, and providing training to those that want to engage. Feel free to contact us at info@scaledsoftwareengineeeinrg.com