Forem: Ryan Taylor

My Delivery Lead Journey

Ryan Taylor — Thu, 13 Oct 2022 21:20:14 +0000

Two years ago today, I joined Focused Labs as a software developer. It was a time where the whole company could fit inside a modest conference room and everyone was writing code for client projects. The story of our growth since then deserves its own blog series, but suffice it to say that there has been a tremendous amount of change since October 2020. The same is true for me.

Today I am announcing my transition to the Delivery Lead team, reporting to our Director of Delivery, Riley Longo. As a software practitioner for over a decade, this is a significant change for me, and I’d like to share my motivations - and why I’m excited to help launch this practice within Focused Labs.

Discovery

I have been a history nut for as long as I can remember, so I jumped at the chance to take an AP-level US History in high school. It was an engaging class (thanks, Mr. Brewer!) and I would often create study guides for myself in preparation for our tests. At some point mid-semester, I shared one of my guides with a friend. The next day, I was surprised to find copies on a number of my schoolmates’ desks! It felt great knowing that my work could help others. Although I didn’t realize it at the time, this positive feedback loop would come to underpin my career as an engineer and consultant.

I entered the professional workplace over a decade ago, and during that time I’ve written software for a number of industries and learned from incredible folks - especially the experts at Focused Labs. Our clients have high expectations for our work and trust us with high-value work, and we consistently deliver working software. Nothing beats a happy stakeholder!

Delivery

Focused Labs has scaled tremendously over the past two years - there are 5x more people today than when I joined. Today, we work with world-class enterprises, innovative Web3 start-ups, pioneering restaurant groups, and everything in between. That’s a lot of working software delivered each week; enter the Delivery Lead team.

Riley joined Focused in early 2022 and quickly started making meaningful changes in our ability to deliver. She forged close relationships with our client stakeholders to ensure our teams are aligned with their goals. Using the Spotify Health Check as a guide, she gave teams a new feedback loop to invest in long-term success. Traditionally, some of these responsibilities would be divided between the project’s technical anchor, product managers, and the sales team. With an official Delivery representative, each of those folks can stay heads-down on their respective practice - and deliver like crazy!

I have anchored a number of projects at Focused Labs and discovered along the way that I feel at my best when building trusted relationships and clearing the way for my talented colleagues to deliver. Through a series of virtual coffee chats with Riley, I discovered that a move to the Delivery Lead team would give me the opportunity to perform these duties at a more strategic level for Focused Labs. When the team was officially launched this fall, I joined without hesitation!

The Future

Although it sometimes feels like I’m drinking from a firehose, my experience as a Delivery Lead thus far has reinforced my decision to step away from the practice of software development and into project leadership. Our clients are awesome, and I’ve enjoyed working closer with them to keep our teams building the highest-value software. The Focused Labs team is incredible, and I’m in awe of their ability to crush code. Our team is building processes and tools that will unlock scale, promote psychological safety, and give our teams the platform to practice their craft.

In some ways, this role is an opportunity for me to capitalize on that great feeling I got back in high school - creating value by enabling others to succeed. As much as I enjoy writing code, it’s far more satisfying for me to see our teams operate with less friction and with full confidence that they are building something that is useful and desired. I am excited for the future, and I suspect I’ll have a lot to share on my 3-year anniversary!

The Delivery Lead team is excited to offer our services! Are you interested in...

A team health check?
Working agreements for a new (or established team)?
Outcome-based metrics for your project?
A psychological safety assessment?

If so, get in touch via email or find us on LinkedIn!

Cover photo is my own: Flickr

What Can a Hackathon Do for your Technical Organization?

Ryan Taylor — Wed, 12 May 2021 14:26:37 +0000

Broadly-speaking, a hackathon is an event that temporarily disrupts "normal" business operations and allows self-organized teams to rapid prototype around their interest areas (technical discovery, business problems, future-looking improvements, etc). Organizations like Atlassian have formal hackathons (ShipIt Days) and others take an ad hoc approach. Rather than re-state what has already been written about successfully planning and holding these events, I would like to share a consultant's perspective on how teams benefit from special hacking events.

Build Competency in Incremental Delivery

As a practitioner of Extreme Programming, I constantly seek to improve responsiveness by shortening feedback loops. In a well-managed hackathon, the entire team is held to a deadline to deliver results; this prompts each team to regularly assess (and adjust) their scope of work to match a target pace of delivery. During presentations, teams can evaluate their contribution relative to their peer teams, providing even more feedback. As this cycle is typically much shorter than "normal" operations (1 day hackathon vs a 1 week sprint), the team will be able to learn and grow more quickly.

Connect to Stakeholders

"I love this new functionality! I can use it to solve [some nagging business problem]!"

By requiring that hackathon teams demonstrate their work in a closing ceremony, participants sees the organization from a stakeholder's perspective. This rapid feedback informs each developer's future work, and product owners will take more innovative risks with the knowledge that their technical team has the capacity to iterate quickly. This is a cornerstone of high-trust teams.

Break Down Silos

Allowing teams to self-organize gives them the opportunity to network and collaborate outside their "normal" domain. As a consultant, I am often empowered to cross team lines (especially during Discovery and Framing), and I can attest to the power of reaching across team boundaries. This effect compounds when teams find synergistic opportunities across functional boundaries. After all, when product and engineering work directly together, the risk of expensive rework drops considerably.

The Gift of Shared Experience

Even in the most tight-knit teams, daily work experiences can be wildly different (DevOps vs Customer Success, for example). Eventually, these functional groups begin to diverge and develop their own work subcultures. Intentionally bringing the team together for a shared set of rituals (coffee and donuts during kick-off, mid-hackathon trivia, project demos, and a hearty round of appreciation and congrats) can stitch the teams back together.

Demonstrate Your Values

Is your company customer-obsessed? Does it cultivate a learning-oriented culture? Do you work hard, play hard? No matter how Core Values are expressed on a corporate landing page, the actual results of a hackathon will open a window into the team's inner dynamics. This is important feedback for organizational leaders, who experience the team differently than their reports. Seeing the team in a different light can be instructive when mapping out the future of a company.

PS: On "normal"

In this article, I want to provide an argument for reconsidering what is "normal" for a team (of any size). Across multiple successful hackathons, I've seen teams produce surprising results in a very short period of time. I believe that a small change in environment (aka: turn on email auto-responders, silence the phones until 4pm, sit with your new team in a new conference room, etc) can have significant positive externalities. With some practice, teams can hold Retrospectives and incorporate hackathon tactics into their daily work, turning the static "normal" to a continuously-improving norm.

Cover photo is my own: Flickr

Faster .NET CI/CD pipelines with test filters

Ryan Taylor — Fri, 15 Jan 2021 15:26:08 +0000

Sluggish integration and delivery pipelines leave developers vulnerable to distraction. If your unit and integration tests live in one .csproj and run in both CI and CD, tune your pipeline stages to run only relevant tests.

The Tests

[Fact]
[Trait("Category","Unit")]
public async Task ThisTest_ShouldBeAUnitTest() 
{
   // Useful unit test
} 

[Fact]
[Trait("Category","Integration")]
public async Task WhenThisThingDoesX_ThatThingShouldDoY() 
{
   // Useful integration test
}

Tuning the Pipelines

To run only unit tests in CI:
dotnet test --filter Category=Unit

To run only integration tests in CD:
dotnet test --filter Category=Integration

Photo credit: Andrew Parnell

Focused On: Culture

Ryan Taylor — Thu, 19 Nov 2020 17:53:18 +0000

At Focused Labs, we hold a weekly Culture Lunch to host important conversations about our work life. Although our company still has its youth, the seasoned team can draw from a treasure chest of experience - and it's important that we share this kind of wealth.

About a month ago, Austin set the stage for a conversation to define our own work culture.

It's hard not to adopt an aspirational tone when writing your culture down (especially for the outside world). Conversations, though, draw out the truth in increments, allowing everyone to contribute their experience. Reading back on our notes from the conversation, I'm noticing that the written product of our brainstorm carries both aspiration and present quality - we set a high standard of quality, but aren't afraid to admit that we have to be constantly improving to maintain that standard.

Having recently joined Focused Labs, this was a critical early opportunity for me to hear the values of my new colleagues directly - and contribute my own. Building great relationships takes time and trust, and this conversation gave me a foundation of understanding to start with. I think the approach of openly mapping your culture can be incredibly valuable, but it is hard to earn the trust that it requires. I hope that by sharing our experience, it can be a guidepost for others - and a force of accountability for us.

-Ryan

Below is the product of our 10/19/2020 brainstorm about Focused Labs culture, lightly edited for readability.

Why We Do What We Do?

❤️ Love your craft
👂 Listen First
🧠 Learn Why

What is our culture?

We build our interactions around collaboration
We deliver efficiently and fast

What defines our culture?

The people
Daily practices
Shared values around work output
Our development approach & methodology
How we communicate
That we have clients
Our mission

What does it mean to love your craft?

I take enjoyment out of what I do
I stay current on the latest and greatest
You try to learn new things in your industry
You can recognize bad craftsmanship
You improve your approach
You represent and showcase the value in quality

Why do we say craft?

It makes it an art form
Crafts can be continuously improved
There are skills that are honed but never mastered
It is more than just specific technologies
Love your craft and then use the tools (rather than loving your tools and then using the craft)
There's passion and dedication to quality
I feel accountable for the output

What tools are integral to our culture?

Pair Programming
Test driven development
CI/CD
Google

Cover photo is my own: Flickr

Cross-Parameter Validation with Spring

Ryan Taylor — Tue, 03 Nov 2020 06:18:00 +0000

With Spring, data validation is a breeze in many common use cases (like validating a method's input parameters) - and is highly recommended for creating robust applications.

Often, developers are called upon to produce software with more complex validation requirements. This guide describes one such situation and proposes a solution that is effective and simple to maintain.

Visit this GitHub repo for a working example of the article's concepts. For a full technical guide for creating cross-parameter validations, refer to this JBoss guide.

Business Case

Suppose you are developing an e-commerce application where users can request for a bouquet of flowers to be delivered to an address within a specific window of time. An order POJO might take the shape of:

package io.focusedlabs.crossparametervalidation;

import java.time.ZonedDateTime;
import lombok.Builder;
import lombok.Data;

@Builder
@Data
public class FlowerDeliveryOrder {
   private String orderId;
   private String recipientName;
   private ZonedDateTime orderPlaced;  
   private ZonedDateTime deliveryStart;
   private ZonedDateTime deliveryEnd;
}

Here we are using Lombok's @Data and @Builder annotations to auto-generate boilerplate code, saving keystrokes and valuable developer time.

Simple Validations

The Bean Validation API can be used to enforce some simple and common validations, such as guaranteeing a FlowerDeliveryOrder will have a non-null orderId:

package io.focusedlabs.crossparametervalidation;

import java.time.ZonedDateTime;
import javax.validation.constraints.NotNull;
import javax.validation.constraints.NotEmpty;
import lombok.Builder;
import lombok.Data;

@Builder
@Data
public class FlowerDeliveryOrder {
   @NotNull
   private String orderId;

   @NotEmpty(message = "Recipient Name must be specified")
   private String recipientName;
   private ZonedDateTime orderPlaced;  
   private ZonedDateTime deliveryStart;
   private ZonedDateTime deliveryEnd;
}

With this simple validation in place, flower delivery orders with an empty recipientName will result in a thrown ConstraintViolationException that can be handled gracefully by the application.

Cross-Parameter Validations

The simple validations above are useful for our application, but what if we want to validate business logic that depends on multiple fields? For example, if the user of the web form selects a deliveryStart that is after the deliveryEnd, the order should not be accepted.

It might be tempting to implement an isValid() method inside the FlowerDeliveryOrder and manually check the result wherever the orders are processed. This may be appropriate sometimes, but the developers must remember to include the check everywhere the order is processed.

Instead, we can introduce a custom validation that inspects both parameters and integrates seamlessly with Spring's bean validation mechanism.

Operating Principle

There are two parts to this solution: 1) a custom annotation to mark the class for validation and 2) a custom validator that encapsulates the business logic to be executed.

Custom Annotation

An annotation is a form of interface and are declared in a similar fashion. Below, we create a custom annotation that can adorn our FlowerDeliveryOrder class:

package io.focusedlabs.crossparametervalidation;

import java.lang.annotation.ElementType;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Retention;
import java.lang.annotation.Target;
import javax.validation.Constraint;
import javax.validation.Payload;

@Target({ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Constraint(validatedBy = OrderDeliveryWindowValidator.class)
public @interface ValidDeliveryWindow {
   String message() default "Delivery Window Start Time must precede End Time";
   Class<?>[] groups() default {};
   Class<? extends Payload>[] payload() default {};
}

In this configuration, the annotation can be placed on classes with @Target({ElementType.TYPE}) and is available to the application at runtime with @Retention(RuntimePolicy.RUNTIME).

The Bean Validation API requires message and groups at a minimum; we can add a payload field to attach custom data to the constraint.

Custom Validator

The @Constraint annotation specifies a class that should be used by the Bean Validation API to perform the custom logic. This class must implement the ConstraintValidator interface.

package io.focusedlabs.crossparametervalidation;

import javax.validation.ConstraintValidator;
import javax.validation.ConstraintValidatorContext;

public class OrderDeliveryWindowValidator implements ConstraintValidator<ValidDeliveryWindow, FlowerDeliveryOrder> {

    public void initialize(ValidDeliveryWindow constraintAnnotation) {
    }

    public boolean isValid(FlowerDeliveryOrder order, ConstraintValidatorContext constraintContext) {
       return order.deliveryStart.isBefore(order.deliveryEnd);
    }
}

Notice that the isValid() method is very similar to how a developer might write an inline validation. This is great news, because it means that existing validations be easily refactored to use this pattern.

Finishing Up

With the building blocks in place, we can now apply this custom validation to our FlowerDeliveryOrder:

package io.focusedlabs.crossparametervalidation;

import java.time.ZonedDateTime;
import javax.validation.constraints.NotNull;
import javax.validation.constraints.NotEmpty;
import lombok.Builder;
import lombok.Data;

@Builder
@Data
@ValidDeliveryWindow
public class FlowerDeliveryOrder {
   @NotNull
   private String orderId;

   @NotEmpty(message = "Recipient Name must be specified")
   private String recipientName;
   private ZonedDateTime orderPlaced;  
   private ZonedDateTime deliveryStart;
   private ZonedDateTime deliveryEnd;
}

Parting Thoughts

While there is some initial time investment required to create a custom annotation and validator, change management becomes much easier from that point forward - and the code can be understood by developers at most skill levels. It is a trusted tool at Focused Labs.

Cover photo is my own: Flickr