Newsflash: Your CEO Doesn’t Give a Flying Fortran About Velocity
(crossposted on the Jellyfish Blog)
It’s time to get honest with ourselves about velocity. Or is it Velocity?. Capital-V “Velocity” has been trumpeted for nearly two decades as one of, if not THE most important way to measure success on the engineering team [it’s also been criticized as dangerous]. The idea here is that by tracking Velocity, we can better understand how much work a team is able to complete in a sprint, and thus we can plan better, see and measure improvement in processes, and ultimately deliver code faster. I want to be clear: innovations in process and the way we work because of Agile have been tremendous. I’m not here to discredit the notion of Velocity and its usefulness on the team itself. But if you’re a VP of Engineering who proudly shows improving Velocity and related metrics to your CEO, watch out! Your CEO probably doesn’t understand what she is signing up for and certainly doesn’t care about actual story points or Velocity, so showing these to her is only decreasing her trust in your ability to do the job.
How many times have I spoken to VPs of Engineering who are struggling to make their CEOs understand or care? They present updates to their executive teams monthly, and each month are asked for something different. At last, discouraged, they call me up and I can hear the exhaustion in their voices when they ask, “What am I supposed to show my CEO?”
“What do you show him now?” is my follow-up question. And the answer is usually something like, “Story points, velocity change, and…” before I cut them off. No wonder their CEO doesn’t care. These metrics have no meaning to the job a CEO does, and worse, they are misleading. Don’t get me wrong, story points and various Agile metrics are great innovations and tools for engineers and teams to help estimate, plan, and communicate amongst themselves [let’s not get me started on the days of waterfall]. But boy have we screwed the pooch choosing the word Velocity. It simply means a different thing to business leaders. CEOs hear velocity when we say Velocity.
Consider the following imaginary situation:
VPE asks CEO if she wants Velocity, to which her response is a definitive “Yes! 100% I want everything up and to the right. Faster, better, all of the above!”
“Great!” VPE responds, “You can have it! In fact, let’s go crazy. Let's give bonuses based off of it!”
Six months later VPE has exciting news for CEO, “Look how well the engineering team is doing. Look how great our Velocity is!”
CEO furrows her brow, “Wait, what?! I still don’t have Widget X and Feature Y that the sales team is screaming for, and no one works past 5:30pm! And now I have to pay out these bonuses?!!!!!
Okay, fine. Maybe that’s a little bit dramatic. But the point holds. While keeping track of Velocity as an engineering leader is helpful to know for the health of a specific team and how the Agile process is working, it is utterly meaningless to the business.
As a VPE, your first job is to figure out what your job is. Your CEO thinks your job is to get things shipped. Quickly. Without bugs. So that her sales team can sell more stuff and existing customers will be happier. Secondarily it is to hire and grow a team for the sake of shipping more things. Whether you totally agree or not, let’s start here. What you communicate with your CEO needs to speak to her expectations of you first. After you successfully communicate that, only then might you be able to get her and the rest of the executive team to engage on the inner workings of your process. This is not to say that all agile metrics are useless to the CEO, but remember that for this purpose, they are only mechanisms to help your CEO recognize how she might achieve the company’s goals.
VPEs, wake up! You’re an executive. Your job is to understand the business, and then project that into your own functional expertise. The CEO wants this, and hired you to do this, even if she doesn’t directly ask you for it.
So, the next time you find yourself wondering, like so many of us have done, “What the heck am I supposed to show my CEO,” try to keep this in mind. You might think about giving a read on the state of your deliverables, an understanding of what key initiatives or types of work are consuming your team’s efforts, or an update on ongoing efforts to improve quality for your customers. Whatever you decide on, instead of showing them Velocity, think about the goals that are important to the business - that are important to the CEO - and work from there.
Professor of Practice & Director, Derby Entrepreneurship Center @Tufts | Technologist | Entrepreneur | Innovation Consultant
4 年Now I have "flying Fortran" stuck in my brain, together with "wake up! You are an executive". It's amazing how VPEs can make themselves forget the latter. Great post Andrew Lau
AI Pioneer | Experienced CMO & CPO | Creative Business Planning + Actionable Strategy
4 年Amazing. Literally working on a measurement for this. How to understand optimization of r&d. This perspective is actually very helpful.
Engineering Leadership | SaaS, Cloud, Agile, DevOps/SRE, Architecture, QA, UX, Vendor Mgmt, Ops Mgmt, Change Mgmt | helping teams build innovative solutions and optimize software development and delivery
4 年I absolutely agree. Your CEO wants a high quality product released frequently, on time and on budget. Velocity is one metric to be used within a scrum team to help a team improve internally. However, it is only one of many metrics that must be kept in balance. It is a very dangerous metric because leaders want to compare the velocity between teams -- which should never be compared because each team 'story point' unit of measure is unique to that team. It is vital to inspire the intended behavior with a balance of metrics.
Director of Engineering @ Hubspot (Hiring!)
4 年It is true that velocity in a vacuum is a dubious metric. But, velocity is useful when trying to communicate the capacity of the team so that prioritization conversations can happen with the business. It's still far from perfect in that aspect too, but it's a starting point.
I help engineering leaders use data to understand what their teams are working on
4 年Well said Andrew Lau ??