Reflecting and Flywheels

Change isn't fun, but it's a part of life.

I've been in a reflective mood the last few weeks. I've gotten a flood of kind messages (which I've deeply appreciated) as well as interesting offers to chat from other founders and recruiters.

I've been eager to provide reference letters and referrals to those I worked who are searching for their next opportunity. Everyone at Thinkific was highly passionate and motivated, and I know any company who hires them will be lucky.

Now that I'm underemployed, I've had some time to dig back into what worked really well as I grew my team from 18 to 146 in 3 years. Which processes held up, which ones didn't, and what knowledge I can share about scaling software engineering for a growing startup.

I'm going to start off with something at the core of how good engineering teams should function, and it's the primary way I've found to create velocity and sprint engagement in software engineering teams. I present, the software engineering flywheel:

Change

Developers must be able to add their new code, documentation and test cases easily into the code base. There must be as few barriers to this as possible. Changes requested must be clean and concise, code must be well partitioned and documented, and local environments must be easy to use.

Deploy

Deployment to production must be fast. Small changes should be able to be staged, tested and deployed to production as fast as possible. This should be minutes or hours and not days or weeks. Developers should not be waiting to deploy.

Feedback

Developers must receive fast and meaningful feedback about their impact. How many people use it? Did they like it? Was there an issue that caused support tickets? Feedback should be shared constantly and used to inform the next Change Many companies have sales and revenue analytics, but don't get critical data back to the team in time to feel engaged and adapt.

This flywheel probably doesn't look dissimilar to what you've seen around agile process, or DevOps culture, and there's a reason for that. It's an approach that's proven and works. It's almost boringly effective, but it's still important to audit the flywheel of your engineering organization and make sure you're measuring it.

If you're feeling your velocity and engagement slow down as an engineering leader, check the elements of your flywheel. Are your project tasks small enough to be a clear change, able to deploy fast, and able to get feedback back to the team quickly? Are engineers spending hours before each change to sync with their local environment? Are people queuing to get their code into prod? Is deploying to prod the last they'll ever hear of how their change is performing?

If you're not directly embedded in your team(s) it's a good chance to go and talk to your engineers, shadow them, and see where the friction is in these three phases. Make sure you have a way to measure each of these three elements at the leadership level, so you can check in on the health of your flywheel. If you're a manager, this is a great piece of data to create and share with your senior leaders!

If you're wondering how to apply the velocity flywheel to your software engineering teams, feel free to reach out! I'd love to chat.

Make room to be awesome,
://Robin