I have spent the better part of my career working in software and technology companies. During my career, I have taken many of the lessons from building great software products and applied them to the wider scope of the company itself. Three of these lessons are applicable to leading and shaping any organization.
Lesson 1: Shift to an Agile Sprint
Too often large software products would be scoped out, planned and managed in a huge “waterfall” project. The problem was that, because of ill-defined requirements or just changes in the competitive landscape, tons of work would be tossed out at the last moment.
Nothing frustrates a programmer more than weeks of their life being thrown away. To cure this, the software world created what’s called “Agile Development.” It can be described with a question: How can the scope of the project be tightened up?
Now software is created using “sprints.” Usually, a sprint is defined as a certain period of time. For example, during a two-week sprint — only the work that can be accomplished in two weeks is planned. That way a team can iterate rapidly on what is built and the next steps.
Often, we find companies engulfed in an annual budgeting or planning process, only to find that six months later none of it makes sense due to large changes in the environment. Shifting to a more agile sprint for an organization can greatly improve productivity and save thousands of hours in organizational effort. At Capture we work on 90-day sprints.
Lesson 2: Use Cross-Functional Teams
The use of cross-functional teams in development changes the game. When you have not only the programmer but also the project manager, the product manager, quality assurance and operations all represented, it generates a better product faster.
At my last company, we broke up our silo-based groups into client delivery teams that included account managers, service delivery specialists, publishing specialists and training specialists. These groups grew to know their clients’ needs better and were focused on exceptional service delivery.
Also, because they all sat in the same room, they could respond immediately to client-related issues. They then met with their functional groups weekly to trade key learnings specific to the group. This concept goes way back to Michael Hammer and the Reengineering the Corporation manifesto of the mid-nineties. Michael was a huge proponent of breaking down the walls of functional silos. Software development and agile company development agrees with Michael.
Lesson 3: Let’s Call a Scrum
The daily scrum is a brief standing meeting that developers have to check in on the status of a project. It is short, with really just three questions: 1. How did yesterday go? Did you complete what you intended? 2. What is the priority today? And 3. Do you need anything to be able to accomplish what you plan to do today?
This meeting, which is accomplished in roughly 15 minutes, is for each member and the leader to hear what is going on and if there are any issues. The leader can make immediate course corrections on setting the day’s priorities or hear about any potential roadblocks. Scrums promote perfect synchronicity. The meeting saves time and effort.
At Capture, we have an all-company, weekly scrum meeting every Monday morning. With all groups reporting, the meeting almost never goes past 15 minutes and is a tool to keep us all going in the same direction.
These three lessons have changed the way I lead a company. Enacting these lessons have worked for me as I am on my third successful company in 15 years. The point is to not waste your team’s time and be incredibly agile or adaptive to the ever-changing world we now live in. I hope you try these techniques and have every bit of the success that we have had the last several years.
By Steve Huey, CEO, Capture Higher Ed