Killing off unplanned work for Frictionless Development with Shawn Kuenzler of Zen Planner

Ledge: Shawn, thanks for joining us. It’s good to have you.

Shawn: Ledge, thank you so much. I’m really happy to be here.

Ledge: Can you give your little two- or three-minute bio just so everybody can get to know you a little bit?

Shawn: I am a director of engineering. I came up through the software engineering ranks doing a lot of Java development. I’ve worked for large enterprises as well as startups through phase 2, through exit. I have a lot of experience developing, growing, and mentoring engineers of all different types ─ mostly software engineers, a little bit on the DevOps side and infrastructure as well ─ and scaling teams mainly now for SaaS-type businesses and products.

I currently work at Zen Planner. We are a SaaS B2B and B2B to C, if you will, as we support boutique gyms and how they run their businesses and how they support their gym members.

Ledge: I think you probably have to have a lot of customer empathy in that space. On your profiles and such, you’re big into sort of Agile and the servant leadership role of the engineering leader. And I always wonder, how have you grown teams around that? What’s that been like to engage and start to bring up an engineering team?

Shawn: That’s a great question. It comes back to culture and values, as an organization, and really getting in touch with the organization’s values and what they put importance on.

So that also comes from the customers as well as sort of “What do your users like?” and really getting to know them.

There are a lot of people who really have a philosophy that engineers should be sort of in this backroom and maybe they’re getting more collaborative with product and such but sort of disconnected from the customer.

I think that can be further from the truth. I think the more that you can engage your engineers with the customers ─ and we do it on the regular basis whether it’s through calls or…

We have the benefit of having seven thousand customers around the world; and so, we have a lot that are local and visiting a cross the gym or yoga studio or a martial arts school and actually getting to see how our users are using the software, solicit some feedback.

These guys aren’t on the front lines but the empathy that they come back with is really incredible. That’s sort of where it starts. So no matter where they’re working, they really have a good gauge on the customers’ needs, desires, likes, and dislikes. And they often get disproven whatever theories we may have about usability and such.

Another thing is within the teams themselves and how important it is to really engage on the EQ level with engineers. I think another faux pas is that we’re all introverted and don’t want to be socializing as much.

Although it’s absolutely true that we have a ton of introverts in our industry, we’re still humans in the end. And so, as we’re expected to deliver and perform as a group, having basic things like trust and empathy for one another and the ability to lower your ego through the ability to fail and how the team responds to how you fail and how they can help pick you up and how we’re all focused on the greater good ─ when you can alleviate those things, that’s when I see the best performance out of engineers.

They’re much happier. They’re able to deliver and they’re able to quickly admit any mistakes or failures because they know that they’re not going to be chastised for it.

Ledge: It’s interesting. I think it almost splits down the middle for me; and maybe we can talk about Type A, Type B, introvert, extrovert, whatever it is.

When I talk to technical leaders, VPs of engineering, what have you, half the guests really want to take this vector of the human side and half want to take the “Let me tell you about my technical stack and the way we do engineering and the CI/CD pipeline” and all these things.

How does that fit together in your daily world? Certainly, you must be doing some kind of architecture, actual technology things. But that doesn’t seem to be the way the you address work as the “passion area.” How does that work because you’re in the engineering seat?

Shawn: That’s a good question. They’re absolutely both passions of mine. I think it’s just that the EQ part of it and the social connections in building those relationships just have to be the cornerstone of it.

Once you have that, then you have a high performing team; then you can go attack the real problems on the tech side.

For my current job, it’s a lot of working through legacy technologies and getting past old patterns and designs that were put into the system that’s quite aged now and “How do we properly support our customers as we build out new platforms on microservices with Kubernetes while still having those dependencies on the legacy system?”

You definitely have a lot of struggles because developers are not excited to work on the legacy necessarily but it’s a necessary evil that we have and there’s really an art to how you can reverse engineer that and use the Strangler Pattern and other items to help you alleviate it and help us get it under control so that we can start to get more of our processing into microservices and start to “dockerize” everything and just get to a better place, in general.

Ledge: And I think that nice middle ground between this sort of EQ-driven people stuff and the technology stuff ─ and you said it off-mike and I’d love for you to delve into what you’re calling “frictionless development” or “frictionless software engineering” and how that’s a goal and maybe the way that you can connect those two worlds together to drive some of that.

Shawn: Exactly! Part of being a successful engineering leader is to truly listen and act on the problems that your team is facing. I think it’s quite common whether in one-or-one or in group settings for leaders to just say, “Hey, what’s in your way? What are your blockers? What can I help you with?” and even though it’s important to ask those questions, a lot of times, you’re going to get the feedback that “Oh, things are going well.” They may not be asking for it because you’re not necessarily in the trenches with them.

And so, as an engineering leader, I think digging into the specifics or enabling people to feel like they can bring up the smallest thing ─ if it’s something that’s slowing down their productivity and how we develop tests or deliver software, I want to hear about it and I want to try to take action on it. I’ll prioritize it and work that through so that they have that “frictionless development engineering.”

It can be anything that helps us to develop whether it’s tooling, performance within laptop, or the delivery pipeline through integrations. How do we automate everything we can in the release process? the testing process?

Let’s look at the handoffs. We have full automation and we have software engineers and tests in my current role but there are still going to be some handoffs, some dialogues between them. Find out where the weak spot is on that. Where is work getting slowed down in the flow?

We’re very big on this and having focus and flow. And so, you can expose and realize those deficiencies really quickly and attack them.

Again, it kind of comes back to the EQ part. It’s just like being able to get people to speak up and be very thorough about everything that we can improve on a process basis and technologically and then hunting those things down whether that’s addressing it through the budget, being able to get more tooling, more expertise, or speeding up a project.

We have one right now that we’re calling just simply “engineering experience” and it’s focused solely on these things. And then, it’s giving that team the autonomy to run with it.

So your objectives are to just reduce friction in dev test and delivery.

How do you go about doing that?

That’s up to them. So I’m sitting there dialoguing with them and helping them to prioritize backlog. But it’s really something that I want them to own. The engineers are the stakeholders here and I want to see what gets them the most fired up and the most excited problems that they want to solve that aren’t necessarily architectural in nature.

We have plenty of those but this team is solely focused on “How do we build and ship product better?”

Ledge: So our listeners are probably thinking, yes, we want that, too; we want to do that.

Let’s talk about a couple of actionable takeaways to just get that started if I’m sort of like “Hey, I’m in the middle of this organization and it doesn’t feel like what Shawn is saying and I’m frustrated and our stuff is breaking and people are kind of not having a good time.”

What are some places that you can actionably actually start doing something?

Shawn: Number one is getting visibility. I think having a good understanding ─ and if you have metrics, it will even help more to “How much unplanned work is there?”

Whatever methodology you’re using, implement your own mechanism for how you track unplanned work. And it’s not just a bug or product management gives you a new priority for a product which derails the sprint that you have ongoing.

I’m also talking about all of those things where we have intermittent test failures or the build process is failing under certain conditions; it’s taking longer to get pull request approved. It can be really anything in the whole realm that is really just sort of that unplanned work and what is blowing up your estimates.

And once you drill into those things, you kind of have not only a backlog but you have finite numbers that you can put behind it, that you can help sell to whether it’s leadership, the business, whoever your stakeholders are or PMO, for instance, so that you can, again, do maybe something similar to what we’re doing where you devote a team to it.

I’ve never had good luck saying, “Okay, we’re going to allocate this much percentage of our sprints to or tech debt.” At some point, you really need to have ongoing efforts or, at least, a dedicated effort for a long period of time to focus on these problems and not be distracted by the day to day so that they can actually allow everybody else to perform better.

Ledge: You make a really interesting point there. Another guest has said similar things ─ that we get obsessed with this idea now of DevOps as if it’s all about tooling. But the reality is that a lot of this is just about ops and making a more efficient operation that, in fact, reduces that friction and doesn’t drive the developers crazy.

And some of that has nothing to do with tooling or reporting or development flows or release cycles; and it really just has to do with “What’s really going on, on the ground?” and what used to just be operations doesn’t have to be called “DevOPs.”

Do you see that happening?

Shawn: Absolutely! It’s funny. Not only do I see it personally in my career right now but I’m hearing about it more and more in the industry. The DevOps movement is sort of cannibalizing Agile, according to some folks. It’s really, perhaps, a strong term but it’s sort of morphing into a larger effort which is, again, as you’ve said, more than just the technology.

And now, we’re talking about the entire process improvement; we’re talking about project management that all of that is a large component within DevOps.

I completely agree. I’ve always defined “DevOps” more as a culture, first and foremost; and then within it, you have tooling, you have processes, you have structures and communication line, and, of course, responsibilities and individuals who have their own roles within it.

But, absolutely, it’s really exciting to see that the two, Agile and DevOps, sort of merging to give us the best output because it seemed like the DevOps movement sort of started on its own and then started adopting more and more of the Agile.

I think that we’re kind of realizing now, as a whole that “Hey, this is sort of one and the same.” In order to deliver and have effective ops, we need to adopt all the Agile practices and, as I’ve said, focus and flow being two of the really big ones that we get the most benefit from.

Ledge: We can dive into the historical context of “lean.” All this goes back to the nineties where you’re talking Poppendieck and it’s about eliminating waste; and lean was always about eliminating waste.

Sometimes, I think we get locked up in this sort of magnificent tooling empire that we can build which probably doesn’t eliminate and it might actually add a lot of friction because, now, I need to figure out how to use all this stuff. The education of the ecosystem now consumes a lot of brainpower.

How do you even choose what to put in place because you don’t want to add more burden? Ultimately, people just want to write code and deploy product. It should be about speed to market.

Shawn: Exactly! And it’s a balancing act. I encourage my engineers to go out, look, and experiment with new technologies and take innovation time to experiment with these as well. And we’ve had some really good findings and we like to consider productionalizing them.

But there’s a balancing act with that even when there’s something such as Kotlin which is getting so much of a following now and it’s really getting some steam.

We have to kind of step back right now and consider, “Hey, do we want a fifth language in our stack? What are the challenges that we have right now when we onboard someone? How long does it take them to pick up the different various languages that we have right now? What does that bridge look like? For how long would you be on Groovy or on Java migrating to Kotlin? Would you do it everywhere? Are you okay with it being piecemeal?”

And so, it’s really sort of stepping back and looking at that big picture of whether it’s tooling or languages, in this case, and having those dialogues but allowing the engineers to sort of ─ I promote them to build their case. I want to hear all the pros and cons that they have. I want to try to shoot some holes in it, too.

But I know that, as a group, we’re going to come up with the best solution. And, if not, then we’re going to pivot again. We can always try something. It’s an evolution, not a revolution.

As long as you give the team the opportunities to explore that but give them the tough questions, too, around the sustainability of it as you think of it as a leader, “How am I going to grow this team and continue to foster and sustain this?” all those things have to be considered with the new tool.

Ledge: Where are some places that you’ve just run down an experimental path in some of these organization stuff and just hit a wall and had to go back? ─ some fail stories. I think it’s easy for us to have hindsight bias when we’re having these conversations and people in the field are going “This stuff doesn’t work in my organization.”

Where are some places that you ran into a wall or you hit a major speed bump? And we can mourn folks who are trying to “hey, watch out for this?”

Shawn: That’s a really good question. One thing that comes to mind is around autonomy. You can definitely go a little bit too far and I want to caution people that it’s okay as well as long as you’re reminding the team that you’re experimenting and you’re willing to change.

For instance, based on some of the ideas in Google’s Work Rules! the Laszlo Bock book, it gave me the idea to “hey, if we’re deciding to change up our team structures, how about letting the individuals choose their own teams?

Based on stakeholder input, we know that, in our direction technologically, we’re going to need some different teams focused on these areas and you, guys, go ahead and literally self-organize and self-form your teams. And let’s see where it goes from there.”

We tried that a few times and we had some good luck but we also kind of got to a point where maybe the strongest personalities in the room were sort of stepping up to take a particular area or people were being so modest that they were saying, “I could be on any of these teams.”

I think we were kind of losing some of the strategy like “How do we work together as a group to strategize around the best formation of a team, the most effective?”

And so, in the end, I think that was sort of an experiment that ─ I don’t want to say it failed but I learned a lot from. It’s tough to sort of bring a group together and just say, “What is the most effective way for you, guys, to form?”

There are some things that, I think ─ being on the sidelines as an engineering manager or an engineering director ─ your vision and insight can guide and help things like team structures be more effective. However, again, I wouldn’t caution people not to do it because it was such a cool experiment; it was such a great learning process.

I think what made me not have to necessarily jump on that, switching back to “I’m going to drive our team structures now” was that I kept reminding the team, “Hey, we’re experimenting. We’re going to see how this goes. Ultimately, we’re looking for the best results for our customers. So help us do that.”

I think the team really respects the fact that we try and experiment; we fail and we just change it up from there.

Ledge: How about a technology path learning experience or learning opportunity, not failure but a place where you ran down a road with a tooling or a framework and you’re just like “Wow, this is not going to work. Back it out?”

Shawn: Let’s see. One, in a former life, we definitely had some experiences with Groovy that way. People were quickly jumping on drinking the Kool-Aid and we were really enjoying the experience. But we realized as we started to replace a lot of our Java implementation code with Groovy that we weren’t getting the performance results out of it.

And so, we ended up reverting a lot of that and going back to Java and just using Groovy for testing which, I think, especially when you couple with it Spock, makes an incredible test framework with the flexibility that it gives us while not taking an impact on performance.

Ledge: We’re in the business of evaluating, vetting, and staffing the very best engineers, and that goes on a technical realm and on that soft skill- and leadership-type realm.

I wonder, what are your heuristics because you do have a high performing team? What do you do when you’re adding people there? How do you measure and make sure that performance is living up for each of the members of your team?

Shawn: In the interview process or once they’re onboarded and staffed?

Ledge: I’d love to know both.

Shawn: That’s great. In the interview process, it, again, starts with culture and values alignment, really digging into what their passionate about and seeing how that passion aligns with ours, and then digging into their specific experience.

I can’t stress enough how important it is. You can get a much better feel from someone as you dig into their stack, dig into their day to day and the challenges that they have. Again, all the while, you’re looking for what they’re passionate about and maybe looking for what they’re less passionate about.

And there’s no problem with that. We’re all going to have some things that we’re not as excited about. But see ─ does that align with the role? with the team?

I want to learn something in the interview process. I strongly believe in hiring people who are smarter than I am, hiring people who are talented in areas that my team may lack. And they’re going to better complement us.

If I leave an interview and they haven’t taught me something about either their systems or the technologies that they’re most proficient in, I either probably haven’t dug in quite far enough or maybe they’re just not up to par on these levels.

So the technical part seems to be controversial lately. I see a lot of bashing of whiteboard interviews; and I do completely relate that it’s not on a day-to-day basis that you’re on a whiteboard fighting for survival.

I like to balance it because I want to say that it is very important that you can communicate your technical abilities and the solutions that you’re proposing to other people.

And so, whether that’s the whiteboard or explaining it or even coding along with us in an interview, it’s very important that I’m not only seeing the technical abilities but I’m seeing how you’re able to relay that because I may be asking a pretty simple question.

They’re really softball-type questions for the type of work and the type of challenges that they’re really facing day to day because, number one, I want to sort of discount for the nerves that you may have but I also want to see how you’re able to communicate something to me when I already have a full understanding of it because I know the answer to this question.

There’s going to be a day when I ask you a question technical in nature and I need to know that I can trust and I’m able to understand the solution that you’re proposing or the information that you’re relaying because if I don’t understand it, it’s going to be that much more of a reliance on the communication.

For me, I think it’s very important to do whiteboard-type or actual exercises where you’re in person. Take-home assignments over the weekend sort of coding projects are fine, too, but I’d really like to see that interaction piece so that I can understand “How will I actually work with this person in the trenches on technology?”

And then, the other part of the question: Once they’re onboarded, once they’ve gotten the environment set up, they’ve gone through some basic training and they’re starting to do some work, we do a lot of pair programming and high collaboration as it is but pairing with somebody who maybe complements their skill set and can give them some room to spread their wings and get an opportunity to work in the tasks and give us some results.

And then, it’s being able to look at the pull request, look at the code that they’re generating, and discuss it in group settings.

We have a lot of architectural-type code reviews that are more focused on design than actual syntax and it’s ensuring that individuals are getting on board with our patterns, our practices. They’re understanding the system and they’re competent. They’re able to describe and tell you what’s going on.

Ledge: Excellent insights! Shawn, thank you so much for joining us. It’s really cool to have you here.

Shawn: Ledge, I really appreciate it. Have a great day, Sir!