Leading the technology function can be challenging for many CEO’s. Yet, for other CEO’s it comes more naturally. Every CEO can learn how to become an effective leader of their technical teams by improving their leadership skills. There are things that will make a difference when leading a technical team, either positive or negative. In this four-part series I will cover those things that will help CEOs better lead the technical function in their company and avoid those things that undermine the effectiveness of their leadership.
In part one and two of this four-part series I discussed the foundational communicational strategies for a CEO leading technical teams. In part 3 I specifically outline what information a CEO should expect from her CTO to achieve engineering process transparency for the executive team and how to get that information.
Engineering Transparency is crucial for CEO leadership.
Some time ago, I was in my CEO’s staff meeting when I got an idea. I was listening to the COO report on our shipping backlog. A winter storm shut down our shipping warehouse and we were behind in our shipments. The CEO wanted to know when we would catch back up. The COO explained the situation in remarkably simple terms: "We have 10,000 orders to ship currently. We expect to receive 3,000 new orders each day and our current shipping velocity is 5,000 orders per day running the warehouse at maximum throughput. Therefore, we expect to catch back up in five days at the current order rate." At that moment, I asked myself, could I explain the work my team does in simple terms like that?
Software engineering work is notoriously unpredictable. The engineering process demands creativity and ingenuity, which sometimes flows freely and sometimes becomes blocked. The engineering process also demands exactness that is not required for other creative projects. For example, when publishing a news story, a news team works collaboratively toward a deadline. While all the facts must be accurate, a typo won’t “crash” the human reading the story. We just read past it. However, computers are not so forgiving. Software engineers rely on 1000s of lines of code from “helper” libraries that often contain bugs. Because of this, software engineers often run into unexpected issues. Finding the root cause of a bug can be difficult and is more analogous to finding a needle in a haystack than searching a carton of eggs for the broken one. This is one reason why engineers struggle with forecasting project delivery dates.
Also, software matures over time becoming stable, reliable and in most cases better at doing what it was designed to do. This process can be sped up, but it cannot be skipped. Knowing what stage software is in must be factored into the equation. For example, an MVP (Minimally Viable Product – the first release of any software) is rarely going to be stable and rarely able to deliver business value. Even after software has been available to the market, the engineering team will continue to mature it through feature refinement until it is a stable, revenue producing product.
Getting to this point is an iterative process of creative refinement overtime. Estimating the date when a software product will be stable and providing business value is difficult to do. There is tremendous risk in all software development projects, more so than many CEOs and CFOs should undertake. Nearly every time I’ve been in a situation where a CEO demanded a date it was his way of trying to mitigate the risk of the project. This strategy doesn’t work. Assigning a date to an outcome dependent upon the software development process is incongruent with the physics of that process.
Making matters worse, engineering teams often provide a false sense of security to the executive teams when they provide a delivery date that is not defensible. And, when the date is missed, they undermine their credibility. So, what is the answer to this problem? How can it be improved?
There is a way to achieve high levels of predictability in the software development process and to achieve a shared understanding between the CTO and the CEO of progress but only through engineering transparency. That all starts with establishing engineering velocity, or the speed at which engineering teams can get something small, called a story, done.
As a CEO, if you don’t know the velocity of your engineering team you need to require that your CTO begin reporting it as a core engineering KPI monthly. Velocity should be described by your CTO using a relative sizing method. The most common way for engineers to do this is using stories and story points. A story is a description of a small work task. Story points describe the complexity of that task. Stories can be either 1, 2, 3, 5 or 8 in complexity. Stories can be larger than 8, but typically if they are they should be broken down into multiple smaller stories.
Relative sizing means stories are NOT estimated in absolute units of time or dollars, but they are grouped by their difficulty. Stories that are estimated as 3s should all be about the same level of difficulty. Similarly, stories that are estimated as 1s are all about the same level of difficulty, but they are also less difficult than 2s or 3s. Over time, engineering teams can get incredibly good at evaluating the difficulty of a story quickly and reliably. They also get good at estimating their ability to deliver a consistent number of story points over an interval of time, typically two weeks. This is the team's velocity!
CEO should expect that each of their engineering teams establish a reliable velocity in story points, or some other relative sizing method. And report on that velocity each month and any gaps between the expected velocity and the achieved velocity. As a CEO or a CFO, if you are receiving estimates or requesting estimates in days or dollars you need to replace that with story points. If you still need a calculation in days or dollars, your CTO can provide you with a cost per point or a time per point based on historical data.
In the same way that weather impacts the shipping velocity of a warehouse, unpredictable events can impact the velocity of an engineering team. Therefore, CEOs should also expect their engineering teams to report on those things that happened during the month that impacted the teams’ velocities.
For example, a CTO might report, “We had a drop in velocity this sprint of 20%. The drop was caused by a loss of two engineers who were out sick.” Or “We missed our velocity goal this period by 10%. The miss was caused by our having to deal with a production issue.” Or “We missed our velocity goal due to our incorrectly sizing a story as 1 story point. When we got into the code, we found outdated libraries (technical debt) that required fixing to complete the story taking more time than expected.”
When identified in this way, engineering teams and their CEO can work better together to fix the problems impacting their velocity and improve the accuracy of their estimates. After about 6 months of following a discipline process of story pointing and reporting on gaps, engineering teams typically will achieve a reliable velocity.
Using this velocity, CEOs can then assign effort to problems effectively. And engineering teams can report on their progress toward creating solutions that achieve a business result. If something unexpected comes up during the engineering process, the team has an effective way to report on the impact, transparently. For example, a CTO may report, “We estimated the feature at 100 story points. We’ve been allocating 20 story points of effort toward the solution per sprint. At the end of the third sprint, we completed 60 points and were 60% of the way to completion. However, we discovered two unexpected blockers in our plan, each 5 story points in size. We decided to keep the project on track by delaying two other stories less critical to the company at this time.”
In this way, the CTO reported to the CEO the problem, a solution, and the impact on other work. This type of transparent reporting can be scaled up to complex projects comprised of many developers and multiple teams.
Once velocity is understood and reported as one of the CTO’s KPIs, CEO can use the teams’ velocity measures to direct the effort of the team more effectively. For example, if the CEO has committed to a revenue growth objective for the company, the engineering team can be given a velocity allocation that specifically directs work to be done on that objective. The CEO can now review progress on her initiative with clarity. For example, the CTO may report, “We have allocated 30% of engineering velocity to be spent on stories that are expected to improve revenue growth. This quarter, we met that objective. I've provided a list of the stories we complete toward that goal and the impact of those stories measured by our KPIs. If you would like, I will convert the points into a dollar figure using historical date so we can evaluate the cost-benefit of the project."
Many CEOs and CFOs make the mistake of allocating dollars or people to an objective. This is a less effective means of getting things done. Dollars and people don’t necessarily correlate with getting stuff done. However, when a relative sizing method is used, it provides a much stronger measure of the work getting done. In other words, only establishing a budget in dollars or people is not enough. CEOs must also know what velocity those dollars or people can produce.
In summary, CEOs must expect transparency from their engineering teams. At the core of engineering transparency is engineering velocity measured in a relative sizing method such as story points. CEOs are then able to allocate effort to specific business outcomes. With that allocation and their objectives, the CTO can then effectively report on their actual achievements and any gaps they have experienced. CTOs and CEOs can then work on plans together to mitigate gaps through reallocation of velocity to achieve the best business outcomes. This type of collaboration is enabled through engineering transparency!