Doug Lloyd Joins Trility as Strategic Client Partner

Trility Consulting® is proud to announce Doug Lloyd has joined the Trility team. From a home base of Chicago, he is working closely with our global Fortune 500 financial services client as a Strategic Client Partner. His ability to develop strong as well as long-lasting relationships translates to helping shape and deliver business outcomes that help position our client’s ability to defend or extend its market share through a simplified, automated, and secured technology journey.

Doug Lloyd joins Trility as Strategic Client Partner in the Chicago area.

Ensuring Mission-Critical Objectives

Doug’s ability to immerse himself into a client’s evolving landscape – from compliance, competitive pressures, and industry trends – will prove effective in helping Trility teams align with mission-critical objectives.

Brody Deren, Chief Strategy Officer for Trility

Trility’s outcome-based delivery method means clients receive observations, recommendations, and options to iterate for the best, highest-priority outcome. Lloyd will help build upon this proven approach and ensure we continue to deliver over and over again on our promises – meeting time, budget, and defined scopes that align with business and technical requirements. 

Comprised of technologists and business consultants, Trility helps organizations of all sizes achieve business and technology outcomes while equipping them for the next iteration in these areas of focus:

  • Cloud and Infrastructure
  • Product Design and Development
  • Information Security
  • Data Strategy and Management
  • Internet of Things (IoT)
  • Operational Modernization

About Trility

For those wanting to defend or extend their market share in an era of rapid disruption, Trility simplifies, automates, and secures the journey and has a proven history of reliable delivery results.

Headquartered in Des Moines, Iowa, with teams in Omaha, Neb., and Chicago, Ill., our people live everywhere and work where needed to help clients navigate their business evolution with certainty.


Set and Manage Expectations Or Work Hard and Fail Anyway

Originally published on LinkedIn.

You work hard and perform well for your client. And somehow, the client is dissatisfied with both the journey and the result. Both parties perceive the other party failed the engagement.

Your options are simple:

A. Grumble about the client’s IQ in private.

B. Debate with the seemingly confused client to set them straight.

C. Together explore where the journey went off course — and correct it.

Who messed up? At least one of you. Most likely, both of you.

Expectation setting and management must occur, on purpose, by both parties, at every milestone and moment of an engagement. Beginning, middle, and end. Constantly. Doing so enables trust through transparency, allows the client to stay in control of the direction, investment, and definition of done, and contributes to the probability of your mutual success. Look at it as the difference between being a short-term vendor or long-term partner.

There are four steps. They have a non-negotiable order. They apply to all people on an engagement. And they must all be present, or the relationship will break down into dissatisfaction, dissension, and potentially dissolution.

Step 1: Set Engagement Expectations

Many people are familiar with contracts. A legal framework between two parties outlining the parameters of the relationship. While contracts, with counter-signatures, obviously matter, they only enable forward movement in a fenced direction. Contracts are permission to engage. Client delight happens because of relationships. And relationships happen through intentional communication and listening.

The entire engagement depends upon a clearly understood, documented, and ratified problem statement and set of desired outcomes. Knowing these two things defines everything that follows in the engagement.

“Why are we here?”

“How do we know when we are done?”

“What must we navigate to get from here to there?”

Figure 1. Set Engagement Expectations at the Beginning (Day 1)
Figure 1. Set Engagement Expectations at the Beginning (Day 1)

With an agreed-upon, documented problem statement and one or more desired outcomes, you are building your house (your engagement) on rock. You have a very high probability of success in this situation because you have mutually agreed upon a point of reference – your starting point.

Without an agreed-upon, documented problem statement and one or more desired outcomes, you are building your house on shifting sands. You have a very low probability of success in this situation.

Interestingly, doing this step alone doesn’t get the job done. There are more steps to setting and managing expectations.

Step 2: Set Deliverable Expectations

Now that we’ve established the problem statement and desired outcomes, we’ve together set the foundation upon which we will deliver value together.

Next, we need to discuss how we are going to work together and what we will be delivering along the way. We’re talking about the operational framework of the engagement.

Figure 2. Set Activity/Deliverable Expectations at the Beginning (Day 1)
Figure 2. Set Activity/Deliverable Expectations at the Beginning (Day 1)

What we know so far on this engagement is the following:

  • Why are we here
  • What will we do together
  • How we will know when we’re done
  • How we are going to operate together

What we have not yet established is living and working together during the journey.

Step 3: Set Operational Expectations

So far, we’ve mutually agreed upon the problem statement, the desired outcomes, what will be delivered, and how we will be doing it along the way. Now we must manage the day to day expectations, operation, and results. We must communicate and listen intentionally.

The purpose of setting and managing daily, weekly, and iteration level expectations is to manage the journey together by bringing the client along with us. We are working with and for our client, not doing things to the client. Build a relationship, not a reporting structure.

For the benefit of all parties, the frequency and method by which we interact and communicate needs to be low ceremony, low overhead, natural, and relational. Short. To the point. Done.

Figure 3. Set Individual Expectations Daily/Weekly/Iteration
Figure 3. Set Individual Expectations Daily/Weekly/Iteration

When a client is actively informed and involved, they have confidence in us, our team, our abilities, commitment, direction, and circumstances.

When a client is not actively informed or included, it is only a matter of time before unanswered questions and concerns lead to distrust and breakdown in the relationship.

Step 4: Manage Expectations As They Change

This step is where a breakdown in relationships frequently occurs and where I’ll amplify critical path considerations.

We had a plan. Something in our control, or outside our control, changed. The change has ripples that mildly or substantially impact our original plan. The change will affect time, complexity, and potentially the look and feel of the solution itself. It may even impact safety and security. You have three options:

Option 1: Try to eat the change on top of your existing commitment.

Option 2: Hide the change and act like nothing happened.

Option 3: Communicate the change immediately and discuss next steps.

Option one is controversial. Option two is unprofessional. Option three has the highest probability outcome.

The first option is controversial. Competitive people will say to each other, “No one cares. Get back up off the ground and get it done. You can do one more.” I’ve done it. It can work. However, you need to know yourself and your team very well, their history, attitudes, aptitudes, and capabilities, as well as the risks, issues, and dependencies. The stakes are high.

Option one can also lead to martyrdom. When a team falls on its proverbial sword to get to the end of the engagement without a hiccup, it can alternatively lead to team disillusionment, burnout, and disbandment. And if you don’t make it to the line, client dissatisfaction. So you may lose your team, your client, and potentially yourself walking this path. It is a gamble.

For some who don’t value people, option one looks useful to them. And for those who believe everyone should just suck it up and get it done, option one seems like a normal choice. As a leader, this is your call. Results are not guaranteed. Casualties may be high.

Option two is immoral, unprofessional, and foolhardy. It isn’t an option for a company, team, or individual who wants to build a reputation of integrity, value, and professionalism. Your last name is your reputation. Your company brand is your professional reputation. Choose.

Option three is best. The benefits include client delight, a healthy, happy, battle-tested team that sticks with you engagement after engagement, a reputation for valuing people, successful partnerships, and delivering value, not just contracts.

Figure 4. Reset Expectations As They Change, Real-Time
Figure 4. Reset Expectations As They Change, Real-Time

If you want to meet or exceed expectations, you have to set them first. And when they change, you have to reset them in real-time. Only when you feel like you are over-communicating are you coming close to communicating enough.

Checklist for Meeting and Exceeding Expectations with Anyone

  1. Before you do anything else, verify the problem statement and desired outcomes.
  2. Recommend options to address the problem and achieve the desired outcomes.
  3. Agree on the chosen direction and approach.
  4. Reiterate the problem statement, desired outcome(s), and chosen direction.
  5. Prior to engagement start: Set expectations clearly by stating what work will be performed, what will be delivered, and any dependencies or risks that exist potentially impacting success. Be sure to articulate what work will not be performed and delivered.
  6. During the engagement: Daily communicate progress. What happened yesterday, what will happen today, and if there is anything stopping, changing, or otherwise altering progress and direction that needs addressed.
  7. During the engagement: Dynamically communicate change and ripples. Communicate the event, the implications, and what it means to the activities, deliverables, and timeline. “We had a plan. Something has changed. Here is what it means to us.”
  8. At the end of the engagement: Communicate results. Begin by communicating what was committed, what changed, and what was delivered.

You will need to dial this into whatever level of detail and frequency the intended recipient desires. Some people value daily updates; others weekly. Remember, to meet and exceed expectations requires constant and vigilant interaction with the person, team, or company with whom you are allegedly providing value. When people don’t hear from you, they form their own mental story-line. Manage the message or have it managed for you.

Be ever-present, over-communicative, and intentional.

Or be second-guessed, questioned and replaced.


Filter the Noise. Communicate and Listen Intentionally.

Originally published on LinkedIn.

Many of us have heard the saying, “Don’t grocery shop while you’re hungry.” The reasoning is simple: If you are hungry and at the grocery, you’ll tend to purchase things that address your sight-driven appetite now instead of your mind/body-driven meal plan later.

In business and technology, many of us have also heard how important it is to know what problem you want to solve before looking at a new tool or process. The reasoning is similar: If you don’t know what problem you want to solve, the flashiest vendor demo, best salesperson, or most impressive UI/UX may influence your purchase. Whether or not the tool solves a problem or creates new ones remains to be seen.

Have a goal or bend to the wind.

And many of us have been taught similar behaviors when it comes to meetings, have an objective and an agenda, or the only real thing that happens during a typical interaction is meandering rubbish.

The above illustrations require intentional plans in advance of the experience. Absent a plan, results vary.

Communicating Requires A Plan. Talking Does Not.

Were you to measure how much talking you do in a single day, what do you believe is the signal-to-noise ratio? How often do you think your message is lost in the noise? Does your method of communicating trample your message?

Figure 1. Speaking without a desired outcome and plan to get there often buries the intended message in noise.

5 Simple Steps to Getting Your Point Across

  1. Determine what you want to happen AFTER you talk.
  2. Plan your points which lead to the desired outcome.
  3. Communicate your points intentionally.
  4. Leave space in the conversation for the other person to talk.
  5. Know when to be quiet and know when you’re done.

Talking is easy. Communicating is hard.

One happens without much thought. The other requires a goal and a plan.

Listening Also Requires A Plan. Hearing Does Not.

How often have you experienced someone talking to you, or at you, where it was difficult to discern the real intent or message? Were you caught off guard? Did you receive a message different than expected? What was your default response?

Similarly, how often do you hear information, whether on the news, radio, social media bitstreams, or at work, where the message seems unwieldy, scary, or overwhelming?

The same is true when listening to someone talk.

5 Simple Steps to Listening to Anyone

  1. Evaluate who is making the statement.
  2. Evaluate what statement they are making.
  3. Evaluate why they are making that statement.
  4. Strip away your emotional response to the person, method, and medium. Decide if you agree or not.
  5. Ask questions. Refer to the communication steps above.
Figure 2. Communicating AND listening must be intentional.

Talking doesn’t guarantee communication. And hearing doesn’t guarantee listening.

Both must be intentional to realize desired outcomes.

Otherwise, it is just noise.

No signal.

Spend (And Enablement) Must Be Intentional

This article was previously published on LinkedIn.

For most companies, there is no room for projects built on hope and wonderment – every dollar matters. Today’s marketplace is unforgiving. Shrinking markets, opportunities, and budgets are forcing difficult decisions. Many companies have already struggled with the choices to furlough, layoff, or otherwise change company spend.

Now is the perfect (and expected) time to analyze spend and understand what investments are intentional, and what investments are designed to bring value to the company. It is also the ideal time to cull projects/spend that seem appealing but have no discernible value in today’s marketplace.

Let’s look at a simple example.

Examine a Typical Digital Transformation Project

Your IT budget is USD10MM. Said budget spans typical OPEX and CAPEX subjects, including people, benefits, hardware, software, office miscellaneous, travel, and training. The number of corporate strategic objectives for the year requires more project capacity than your headcount. Each of the lines of business (LOB) want their needs addressed, each of them vying for priority over the other. Some of us call this a typical Thursday.

A few folks on your team have ideas that may potentially transform your IT operation, enabling quicker response times, more straightforward systems changes, and the flexibility to adapt to the changing winds of the business happening now and in the anticipated future.

It appears the idea may simplify operations and lower long-term spend. While everyone else is fielding daily lights-on operations, handling one-to-many (1:N) projects, participating in meetings, and performing hands-on-keyboard technical things in fits and starts, you green light your lieutenant (Lt.) to explore new ideas looking forward to the future.

Across the next days and weeks, the exploration project updates happen in hallways, at lunch, over a few coffees, and dinner one night. The updates are exciting, new tool possibilities pretty cool, and the potential for a modern architecture changing the operation for the better are enlightening.

As weeks turn into months, the excitement builds as new programming languages, tools and ecosystems coalesce into a working prototype of things promising an upgraded tomorrow. Your Lt. asks for permission to bring a couple of other folks on board the exploration project to increase velocity. You approve. They’ve privately named their project, Rocket Man, to illustrate the value of this project promising to propel them into new territory. Meanwhile, your role as CTO continues to require constant progress on Line Of Business (LOB) projects, executive meetings, prioritization activities, capacity challenges, attrition, and budget revisits due to market shifts.

Nine months elapse. Seven people are now full-time dedicated to the informal, doesn’t formally exist yet project, which has consumed 15 percent of your annual budget, and you need answers. Finance is asking why seven folks are logging time against overhead time codes, LOB leaders are knocking down your door for solutions, and your CEO is hearing some hallway chatter making her curious how you’re doing.

At one point, a peer jokingly jabs asks about your kids and their toy-box project, but you smile, brush it off, and redirect the conversation.

Post-haste, you ask your Lt. to provide a purposeful briefing to understand money spent, time elapsed, people, responsibilities, progress, and definition of done. You privately wonder how this effort made it so far down the road.

The team presents a sharp, polished presentation deck complete with video clips explaining tool chains, sharply drawn architectural diagrams, a few technical cartoons, code snippets in new programming languages not used in today’s operations, and a component architecture status report showing percentages of things done, in progress and not started. They smile with the pride of success, turn off the presentation, turn to you, expect validation, encouragement, and continued support. They feel they have worked hard and performed admirably.

CTO: How do you know when you’ll be done?

Lt.: We’re working to decide on the final programming languages, tools, and solidify the architectural direction. We will have answers in the next couple of weeks.

CTO: When will this be ready for production?

Lt.: We don’t know yet. We’re still working out the plan.

CTO: We’ve spent USD1.5MM to date. This spend is now on the radar of the larger company. How much money do you need to finish the prototype?

Lt.: We’ll come back to you with a number.

At this point, the CTO knows a bunch of money is spent, doesn’t know what he has, when he will have something usable, or when he will be done spending money. At the same time, he is behind on LOB prioritized and funded projects, is still fixing financial spend details with the CFO, and needs to manage the message with his boss, the CEO.

The options appear to be:

  1. Formalize it, publicly communicate and fund it
  2. Kill it, shelf it for later, and tag it as R&D with Finance
  3. Let it go on for a while longer until the answer reveals itself

What did the CTO do well, and what must the CTO change?

What the CTO Did Well

  1. Encouraged innovation
  2. Trusted and supported his team
  3. Gave people latitude to learn, grow, and become more
  4. Invested in the future proactively

What the CTO Must Change

  1. Trust people while additionally setting up engagement parameters
  2. Define desired outcomes in advance of engagement
  3. Set and manage Keep Going / Let’s Stop triggers
  4. Set, manage and communicate expectations laterally and upline

Read Leadership in Absentia for additional suggestions on ensuring people are empowered to grow, learn, and care about successful outcomes within a premeditated framework.

10 Recommendations Enabling Exploration and Discovery

  1. Encourage new ideas, approaches, and solutions at any time, from any person, on any subject. Permit people to explore.
  2. Have a single repository for all new ideas to be logged, explored, collaborated, prioritized, and developed.
  3. Consider designating time per week or month for people to explore, discover, prove, or disprove ideas and assert priority.
  4. Consider having regular lunch and learns or spontaneous blitzkrieg meetings whereby authors present and explore their problem statements and innovations collaboratively.
  5. Have teams create and review value propositions to receive formal funding.
  6. Use Go/No-Go decision milestones during the funding period.
  7. Encourage folks to explore their ideas on their own time or designate hours per week or month where folks are free to experiment with their ideas.
  8. Define funding parameters within which each effort must exist to manage time, risk, security, and spend.
  9. Know when to say when.
  10. Set and manage expectations with your uplines and peers.

We are all required to change, adapt, and evolve regularly. Exploratory thinking and testing is an enabler. The CTO did the right thing investing in the future and trusting his people. And the Lt. did the right thing working to discover options for the future. They were both intentional.

However, desired outcomes, operational parameters of the engagement, and go/no-go decision points need to be articulated and agreed upon in advance. Outcomes, spend, and activities must also be intentional. Else, it will only look like a toy box project leaving everyone wondering what value they are receiving for the spend.


Approaches to Leadership: Hurricanes, Wakes, Ripples and Deserts

This article was previously published on LinkedIn.

Leadership styles make or break companies. Why?

Teams reflect leadership.

It doesn’t take long to look in the mirror. If you don’t have a mirror, it only takes a cup of coffee to ask some teammates to reflect on your history working with people, projects, teams, and companies.

If you’re dissatisfied with your company, teams, projects, progress, and output, look in the mirror first. It could be you

Hurricane Leaders

Hurricane Leadership

Erratic, unpredictable, contrarian, immeasurable collateral damage

No one sees you coming. No one knows where you’re going. Teams see you’re on a rampage, but don’t know how to help. So, they stay out of the way and otherwise ensure damage to themselves and their interests is minimized – hoping you don’t swing back around for another go. The general assumption when you are present is a higher probability of storms with damage than rain enabling growth.

Your presence breaks things, sometimes people.

Leaders Who Leave Wakes

Leaders Who Leave Wakes

Purposed, directional, controlled, consistent, enabling

People see where you’re going and want to be part of the journey. And because of your plan, communication, and choices, teams who journey with you can be part of an experience that changes in all directions.

Because of you, those who journey with you can make use of the wake you leave behind in a constructive, growing, and useful manner. Your wake changes the company, culture, people, and teams.

Leaders Who Leave Ripples

Leaders Who Leave Ripples

Modest, enjoyable, optional, a lovely time

Who doesn’t love a pleasant afternoon aboard a boat with friends? The gentle hum of the motors barely noticeable, a warm, gentle breeze, the time just between a hot afternoon and dark evening, both without clouds. Sunset.

Leaders who want a sunset cruise with chums enable others to relax. They need only aspire to the level exemplified. No need to rock the boat, make big waves, get out there and jump wake walls, increase skills, or otherwise even get out of the boat. This leadership style is peaceful. People like to be with you knowing that the demands may be low.

Your ripples eventually make contact with other parts of the ecosystem. To what extent change is stimulated, at what velocity or frequency may be variable, even unnoticed.

Desert Leaders

Deserts Leadership: Not Present

When there is no vision, mission, set of objectives, or desired outcomes, people do not know why to gather, what to work on together or even why they, or the company, matter. Leaders are looked upon to cast a vision, rally the people, lead the charge, and foster culture. In the absence of present, active leadership, folks tend to look for someone else, somewhere else, where they are recognized, valued, a part of something bigger than themselves.

Your impact on the culture, team, project, and company is negligible. There are no hurricanes, wakes, or ripples. Nothing is happening as a result of your leadership.

How Do You Choose Your Leadership Impact?

  1. Know what problem you want to solve
  2. Know what desired outcome you want after solving the problem
  3. Plan your leadership approach to foster desired change
  4. Communicate the what and the why of the problem and outcome
  5. Include the teams in solutioning, structuring, and implementation
  6. Continually adapt your leadership style contextually

What type of teams do you have in your company? They usually reflect leadership.

I’ve made a commitment to write more articles in 2020. It is material we discuss every day at Trility and with our clients. If you’d like to keep informed and even interact, please connect or follow me on LinkedIn. Or we can send you an email

We are also always looking for system thinkers to join us – those who can see the larger landscape and do the work as well.

Operational Modernization

A Basis for Automation, Part 2: Inclusive Continuous Delivery

This article was previously published on LinkedIn.

You are the Delivery Manager. There are 1,000 people in your organization. Twenty-five of them are on your project. Of the 25, six defined “done” for this deliverable. In your opinion, you delivered some of your best work. Twelve people, not on your project, come out of the woodwork telling you things are missing from the deliverable. You’re surprised. The project sponsor is mad. Your big boss wants answers. And the delivery team wonders why you’re letting people say harsh things about the deliverable and team without a fight. The deliverable cannot go to market until you get this figured out. What happened?

Many people suggest this is a problem with the Delivery Manager. Some suggest that stakeholder requirements were not identified and managed correctly. Others blame tools, processes, procedures; some notice internal kingdom-building, protectionism, and turf wars. A few even suggest the technologists who built the system are basement-dwelling anti-social figures of darkness who deliver what they want and don’t seem to know or care about business needs. While these conversations may be entertaining, in the end, finger-pointing conversations don’t solve the real problem.

  • How does it even happen that we miss stakeholders and requirements?
  • How do we ensure we’ve identified and included all pertinent stakeholders in project definition, verification, and validation?
  • How are we going to deliver all these additional requirements, definitions of done, and system attributes?

The answer is simple and accessible.

How Do We Miss Stakeholders and Requirements?

The problem starts inconspicuously at the beginning of the project when people are classified as one of two groups: requesters and builders.

Software Builders vs. Software Requesters
Figure 1. Projects are set up to differentiate “us” and “them.”

After that, requesters are decomposed further into three groups – now, later, never.

  • We’ll concentrate on these roles/users/user classes now,
  • We’ll consider those other roles/users/user classes later, and
  • We’re not going to consider these roles/users/user classes
Backlog Prioritization in Software Development
Figure 2. Groomed backlogs manage scope, priority, risk, time and cost

From above, the “deliver now” requests are then prioritized even further into:

  • We’ll do these things first,
  • We’ll do those other things immediately thereafter, and
  • We’ll do these other things later.

It seems deductively logical and very efficient.

Grooming a backlog is a learned skill. And when done well, it enables team focus and success, manages project risk and reward, as well as provides iteration upon iteration of value to the targeted stakeholders. A single, frequently curated, and prioritized backlog is a healthy core behavior of successful projects.

Over-zealous backlog grooming may also be why you’re missing expected functions, features, and attributes when projects are delivered. The project team thinks they are done, and yet things are missing.

Have you considered that teams are so efficient at curating the backlog that stakeholders and requirements are collateral damage?

How Do We Make Sure We’ve Included Everyone Necessary?

Create a cross-functional strike team responsible to securely operationalize the planned project deliverable – from inception to delivery. A project is not just documents and code. Projects operationalize ideas to serve clients, expand opportunities for growth, and generate revenue.

To securely operationalize requires a complete end-to-end cast of people from project sponsorship to design, develop, test, inspect, and secure to back-office operations including finance, procurement, sales management, and support services.

Cross-Functional Strike Team, (c) Trility, LLC
Figure 3. Cross-Functional Strike Teams are special-purpose teams designed to discover the superset of requirements ensuring common knowledge, purpose, priority, decision, investment, and commitment.

Then as a team, perform the following steps incrementally and iteratively through the course of the project – and support – efforts:

1. Identify the problem statement and desired outcomes.

2. Identify the work and definitions of done per work item. Focus upon roles, capabilities, and attributes.

3. Structure the work into independently digestible chunks with clear definitions of done. Note: Common today is the use of Epics, User Stories, and Acceptance Criteria.

To have the highest probability of delivering something useful to most, we need to know what they want by including more people, more roles. Conversely, to have the highest probability of dissatisfaction with the deliverable, exclude people and guess on their behalf.

You may be wondering, if there are going to be higher numbers of stakeholders and higher amounts of requirements, how are we going to get this done without lengthening the project, increasing the cost and adding to staff?

Enter the role of automation.

What Is Automated Continuous Delivery?

Developers are expected to do many things. Writing code is a means to an end, not the deliverable itself. To deliver more value, minimize context-switching, and increase flow, developers seek optimizations.

For some, optimizing means cutting things out and kicking them down the road. For many others, optimizing means automation.

What do I have to do?

What can I aggregate, separate or eliminate

What do I have to do manually?

What can I automate?

Continuous Integration, Continuous Delivery
Figure 4. An example of a continuous flow experience for a developer.

A fantastic result of developers who seek efficiencies through automation is that those same efficiencies can be used all along the delivery pipeline and out into general availability/production.

For some great examples of how developers seek to simplify through automation, look to Will Rubel, and his four-part conversation on test automation in delivery pipelines.

Figure 5. An example of continuous flow at the (team, project, program, division, enterprise) release level.

What about all of this makes automation and continuous delivery inclusive?

Remember the cross-functional strike team previously discussed? Many times, stakeholder numbers are minimized to control scope, time, cost, risk, and complexity because the developer, respectfully, is the constraint.

Automated continuous delivery pipelines change the math regarding how many stakeholders, requirements, and developers are required to deliver value.

With automation, we decouple the dependency between requirements and the capacity to meet them.

How Will We Deliver More Value with Fewer People?

There are three keys to moving into this new paradigm:

  • Use your cross-functional teams to define work.
  • All work must have definitions of done articulated as acceptance criteria.
  • All acceptance criteria become automated tests that are applied to user stories on the continuous delivery pipeline.
Strike teams build automated tests/checks in the continuous delivery pipeline. (c) Trility, LLC
Figure 6. Strike teams build automated tests/checks which are included in the continuous delivery pipeline designed to prove or disprove a user story is still behaving as expected.

Cross-functional teams contribute to the discovery, definition, and prioritization of roles, capabilities, and attributes in the backlog and participate in demos to verify value. The smaller strike team who makes the code commit, builds, verifies, and delivers the solutions also creates automated tests along the way.

Together, they rely upon definitions of done, automation, and the continuous delivery pipeline. Together they deliver a solution.

Principles for Delivering the Solution Everyone Wanted

  1. Let anyone at any time, for any reason, add any ideas, suggestions, or requests to the backlog.
  2. Curate, cultivate and prioritize the backlog perpetually, daily
  3. Use cross-functional delivery teams for backlog prioritization, epic and user story build-out, design, development, inspection, testing, and delivery behaviors from beginning to end of the project.
  4. Tell teams to focus on flow.
  5. Use version-controlled, continuous delivery principles from end to end of the project, i.e., from developer out into product implementation support and evolution (General Availability (GA)).
  6. Automate. Automate. Automate. If you would like to further explore the reasons and value behind software automation, refer to A Basis for Automation, Part I.

We don’t need to run from, defend against or hide from stakeholders and their expectations. Instead, invite them. Then continuously curate, prioritize, and automate their feedback.

How Do I Get Started?

If you’re perplexed by delivery teams saying they are done, but the solution delivered seems short on features, functions, and value, the conversation more likely lays around how software is being defined and delivered instead of what.

  • Ask your teams how they choose stakeholders.
  • Ask your teams how they choose requirements.
  • Ask your teams if, how and to what extent they use continuous delivery principles and automation. Do they pursue continuous flow?

Their answers point you to your next steps.

Interested in Examining Flow?

Trility joined Bâton Global for a podcast series on Human-Centric Transformation. In the four-part series, they discuss how leaders and technology can simplify and automate processes for team members, stakeholders, and customers.

Before you listen, view our companion infographics highlighting key takeaways as these organizations discuss how to better respond to industry headwinds and pressures.


Nathan Levis Joins Trility as Senior Sales Engineer

Trility Consulting® is proud to announce Nathan Levis has joined the Trility team as a Senior Sales Engineer. In this role, Levis will help identify and craft solution engagements for clients to simplify, automate, and secure their paths forward.

Leveraging his breadth of technical expertise and an open-minded approach, Levis will focus on building partnerships to ensure organizations defend or extend their market share in an era of rapid disruption.

Nathan Levis Joins Trility as Senior Sales Engineer

A Holistic View of Business

Nathan brings invaluable Cloud, DevOps, Software Engineering, and agile experience, coupled with a keen interest in holistic business impact to help companies deliver on their most important technology-enabled priorities. He will be a great asset for our clients and for the Trility team.”

Brody Deren, Chief Strategy Officer for Trility

Trility’s outcome-based delivery method means clients receive observations, recommendations, and options to iterate for the best, highest-priority outcome. Levis will help build upon this proven approach and ensure we continue to deliver over and over again on our promises – meeting time, budget, and defined scopes that align with business and technical requirements. 

Comprised of technologists and business consultants, Trility helps organizations of all sizes achieve business and technology outcomes while equipping them for the next iteration in these areas of focus:

  • Cloud and Infrastructure
  • Product Design and Development
  • Information Security
  • Data Strategy and Management
  • Internet of Things (IoT)
  • Operational Modernization

About Trility

For those wanting to defend or extend their market share in an era of rapid disruption, Trility simplifies, automates, and secures the journey and has a proven history of reliable delivery results.

Headquartered in Des Moines, Iowa, with teams in Omaha, Neb., and Chicago, Ill., our people live everywhere and work where needed to help clients navigate their business evolution with certainty.

Operational Modernization

A Basis for Automation: Predictable, Repeatable, Auditable Workflow

This article was previously published on LinkedIn.

I remember a math teacher from long ago telling the class, “Until you know how to do the math with a pencil and eraser, you cannot use a calculator.” And I have subscribed to this logic my entire life journey. Learn everything at the most basic level. Understand why not just what. Optimize the information after I understand so I can then learn even more. This is one of the great experiences that made me want to be a lifelong learner.

Another was a physics teacher sitting beside me, walking me through a book from the Smithsonian Institute on space. His questions to me, as we thumbed through the pages looking at high-resolution pictures of the planet were simple, “Can you imagine what it would take to travel to that planet?” “What do you think it would take to live on that planet?” And I, thereafter, sought to understand what it would take to solve these problems. This experience taught me, “Think very big and do not be intimidated by large, opaque, complex, high-risk problems.”

I also remember, with great sadness, when I realized there was more to learn than I would live long enough to understand and value.

All Big Things Become Small Things

So, I looked for methods of discovering, organizing, and leveraging greater volumes of information in my everyday life. I needed a way to discover and appreciate the depth and breadth of a seemingly infinite set of bodies of knowledge while accepting I only have one lifetime to do it. I needed a way to take big things and break them into small things so I could choose what, when, where, why, and under what circumstances they may directly apply, or cross-apply, to other endeavors in my life.

Common words for organizing big things into little things and so on include paradigms, frameworks, patterns, templates, reference architectures, taxonomy, decomposition, configuration management, deconstruction, classifications and even Table of Contents.

Figure 1. Big things decompose into small things.

To the dismay of all logophiles out there, I’m going to condense this discussion to one word – patterns.

I look for reusable patterns in everything. Patterns to understand things around me. Patterns to organize. Patterns to do work. Patterns to assess risk. Patterns to deliver. Life is full of reusable patterns.

Life is full of reusable patterns.

So, when you’re trying to understand something big, break it down into parts and pieces. It will be easier to understand, organize, prioritize, and build back up again at scale because you will discover one or more patterns. Whether something is broken down to the atomic level or to user classes, epics and user story threads depends upon your project.

Work Has A Predictable Pattern

Most people understand the idea of work. I am cold. I put on a coat. I am warm. I have dirty dishes. I wash them. I have clean dishes.

State A. Do something. State B.

And many people want to see the results they want to see – right now.

I want pecan pie right now. I want it to look and taste just like what my Grandmother used to make for me on holidays and birthdays. My Grandmother has passed away, I don’t have her recipe and I failed to ask her to teach me how to make the pie. I want it nonetheless. Now. Exactly the way she used to make it. With whipped cream. Do not fail me, maker of pecan pie.

What I want and what I can get is dependent upon an ability to:

  • See the big thing (pecan pie);
  • See the parts and pieces (ingredients); and
  • Understand the method (order and method of operations).

Whether I’m making Grandmother’s pecan pie, building a barn or implementing a continuous delivery pipeline in the cloud, they all require the same steps, in the same order, to begin and complete the work.

The basic pattern of work looks like this:

  • a request for work,
  • entry criteria (criteria by which we agree to start work),
  • a method of doing and a method of checking work,
  • exit criteria (criteria defining “done and acceptable”),
  • and a deliverable.
Figure 2. “Do Work” – A simple view of how work happens for one person.

People Do Not Perform Consistently

The unpredictable, non-conforming, variability of people is one of the things that makes life an adventure. People and their culture are rich and unique, and our memories and the stories we tell about them form a vibrant tapestry.

When it comes to work, if we know the pattern of work, then why do so many hard-working teams fail to deliver, let alone deliver well?

Humans are not automatons. Humans are, by nature, variably behaved, expressed and experienced. For 100 people to complete 50 individual tasks 100 times in a predictable, repeatable and auditable manner is a pretty tall order. Which may explain why a grande caramel macchiato retrieved from the same chain store in different cities tastes different so often. There is a recipe, an order of steps and method. Nonetheless, sometimes the coffee tastes like the highly caffeinated liquid weight gain I expected and other times a painful waste of money.

If there is a pattern and the work is human and manual, there will be variable results. Human results are variable. Why does only one team win the annual football bowl game while others do not? More interestingly for our conversation, explain why that same team doesn’t win every single year of their existence. Variability.

We know what a predictable, repeatable pattern of work looks like and we know how human variability can impact that pattern in everyday life.

Now let’s look at what happens when we have many people.

Work Patterns Get Complicated As They Scale

Assembling around an objective to achieve a result is seen in all of nature. It isn’t unique to humans.

Bees. Ants. Animal packs. Sports teams. Military units. Projects.

For Humans, work becomes more complicated as the number of people involved increases. With more people come more units of work, more steps and more latency between steps.

Consider the following behavioral pattern many of us see in organizations, “This team does work, then this team does work, then this team does work.” Have you seen this before?

Queue work, start work, do work, hand-off. Repeat.

When we watch ants decompose food, there appears to be a constant flow of activity. When we watch bees collect honey, we see the same characteristics. Flow.

When we watch people on projects, it simply isn’t the same.

Imagine being in the passenger seat of an old 1968 F-150 pickup while a teenager is learning to drive a stick-shift. Now imagine every time said teen pops the clutch, taps the accelerator, hits the brakes, or all of them at the same time, your head rocks back and forth between the glass behind you and dash in front of you. There was no padding in the dashboard. Learning to control the clutch is a practiced, learned behavior. Learning to push the accelerator while letting off the clutch is also a learned behavior.

Flow is a learned behavior. Flow must be sought on-purpose.

Now, imagine smacking your face on the dashboard, glass or both every time work moves from person to person on a project in your company. Start. Go fast. Stop. Start. Stop suddenly. Kiss the dashboard.

What if your face was the barometer of your organization’s flow? Imagine increasing the number of people, concurrent projects and tasks to span the company and you are the only person who hits glass and dashboard for all projects, all people, all steps, all starts and stops. Need a helmet?

If you think I’m exaggerating to make a point, I am. A little. The stick shift story is real. I feel bad for my dad and all the watermelons we ran over in the field that day. He ended up sitting in the seat sideways with arms against the seat and dash in a self-defense position. If there had been predictable start and stop patterns that day, perhaps he could have navigated the situation more enjoyably. I still remember the look on his face.

Figure 3. “Do Work and Wait” – A simple view of work for multiple people.

When it comes to performing work and delivering results, the ideal experience achieves a smooth flow of work being performed, with little to no wait times in between steps, and smooth transitions.

Wait time and unpredictable transitions likely cost my dad time on this earth realized as dynamic, premature aging. Wait time and unpredictable transitions cost companies time and money.

The “start and stop” method is also known by some as the “throw it over the wall” principle.

“My part is done. Worked for me. Good luck!”

We want flow like ants and bees. We more likely experience starting, stopping and pain like my dad while teaching me to drive a stick-shift.

Manufacturing Controls Flow-Through Batch Sizes

If you and I are on the same page regarding the value of flow versus kissing a dashboard with your face, let’s talk about how to get there.

Decades ago, the manufacturing industry began the use of assembly lines (automation) to increase flow, throughput, predictability, quality and manage their scaling economics. They received another boost in productivity and value when they moved from large to small batches along the same assembly line. Wait times decreased and flow increased.

And due to batch sizes, their ability to adapt to change increased.

In the manufacturing world, wait times (inventory in a wait state) are considered unrealized revenue and therefore waste. Manufacturing supply chains, therefore, seek to eliminate waste. They build things to make money. They do not build things to store them in the supply chain. The key? Flow.

Figure 4. Too much in-flight, undelivered work is unrealized revenue.

If warehouses full of product are considered unrealized revenue and therefore waste in the manufacturing industry, how do we then categorize in-flight, incomplete, undelivered or otherwise unfinished software solutions in companies? What do you think that implies with regards to the numbers of in-flight user stories or numbers of in-flight software projects?

What do you think happens when we introduce the idea of rework?

Work Always Has Rework

Ideally, when we run projects, things always go as planned. And when they don’t? We end up dealing with two subjects that weren’t in the original plan – technical debt and refactoring.

Technical debt is defined by work you know you need to do now, but decide to kick down the road until later. This creates additional work in the backlog. Just like interest rates on debt, the longer it sits there, the more time, complexity and/or cost it will take to address. Technical debt is work.

Refactoring is defined by changing, modifying or otherwise evolving something from a previously acceptable state of existence to a new and improved state of existence for the purposes of delivering desired value. Refactoring is also work.

Figure 5. Rework – “I found a problem. What do I do with it?”

When John finishes his task, the deliverables move down-line for Jane to complete her task. Jane finds a problem with the inherited deliverable and either fixes it, ignores it or sends it back up-line for John’s eventual attention.

If Jane fixes it on behalf of John, was it correct and complete? If she ignores it, will it be found and addressed later? By whom? If she sends it back up-line, how will John know? And when will John get to the refactoring work given his existing backlog of prioritized work?

The problem discovered by Jane impacts her ability to complete planned work. And depending upon her decision, it will become work for one or more others.

Now multiply John’s and Jane’s experience by the numbers of people, teams, projects, stories, and associative decisions to acknowledge, fix, send it back up-line to someone else’s queue or ignore it altogether.

This churn contributes to wait times between steps. And if a person doesn’t plan for rework, it also contributes to cranky people.

Rework happens. Plan for it. Manage impact to flow by decomposing all work into small, edible pieces. Manage your batch sizes. Seek flow.

How Do We Achieve Flow?

To consider automation, we have to first understand work, batch sizes, and flow. Otherwise, with automation, all we’re really doing is taking bad things, making them go faster and calling it digital transformation.

Steps to achieve flow:

1. Manage batch sizes. Break big things down into small things.

2. Minimize and eliminate wait times between steps and people.

3. Plan for, invite, and accept rework. Manage it through batch sizes.

4. Automate.

5. Repeat.

Automation is not the goal. Predictable, repeatable, auditable flow is the goal.

Automation is only the medium.

My math teacher has made sense for a very long time.

Pencil first. TI-88 programmable calculator second.

Read Basis for Automation, Part II, to learn the steps for ensuring a project team addresses requirements and prioritizes backlog before automating a continuous delivery pipeline.

Interested in Examining Flow?

Trility joined Bâton Global for a podcast series on Human-Centric Transformation. In the four-part series, they discuss how leaders and technology can simplify and automate processes for team members, stakeholders, and customers.

Before you listen, view our companion infographics highlighting key takeaways as these organizations discuss how to better respond to industry headwinds and pressures.


Defining Key Attributes of Exceptional Delivery Managers

This article was originally published on LinkedIn.

Monster team sizes, long delivery timelines, embarrassing expenditures, more headaches than deliverables, hypothetical and yet intangible value, unknown compliance and team attrition. You thought you had the right leadership team in place to deliver your desired outcomes. Now you’re wondering.

Reliable delivery is something we all seek in our organizations. We all face the same questions when approving priorities and efforts, allocating money, forming projects, teams and, in particular, appointing leaders.

We all ask: “What problem do I actually need to solve?” And, “Who can I depend upon to make sure this happens?”

It always comes down to leadership. While it seems like it should be easy, finding the right person is actually hard. We don’t know we’re staffed incorrectly until we’re already heading off the road (or in the ditch).

Title history, degrees, professional certifications, training programs and certificates of completion should, in theory, weed out people who can deliver from people who might not or cannot. In my experience, all of those things point to someone who desires learning, advancement and success, yet doesn’t always equate to great attitudes, aptitudes, abilities or results. In other words, often those things are false positives.

Then how do we increase the probability of finding someone who will predictably and repeatably deliver value for our organizations?

If you’re looking for a shortcut, I don’t have one. I do, however, have some experienced recommendations. And if you take the time to follow these steps, the return on investment window is long.

Your company is on a journey of growth, opportunity, change, aggressive pursuits, adaptation, highs, lows, easy days, hard days and sometimes ludicrous days. You need someone leading your projects who is on a journey just like your company. In the fight, not just studying it over a weekend for a two-day certificate of completion and calling it good enough.

For me and my teams, there are three classes of information I explore when considering teammates as members of our delivery teams. It isn’t foolproof. However, it has been very reliable. I have found great people who delight our teams and clients. I ask and research the following areas:

  • What behavioral attributes do we want exhibited in our company and people?
  • What knowledge attributes do we expect leaders to gain or bring with them?
  • What experience attributes do we expect leaders to gain or bring with them?

A challenge for anyone trying to find the right people is with so many titles, words, certifications, methods, philosophies, influencers, founders, books, conferences, etc., how do we know which ones are meaningful at all, let alone for our unique context?

For example, what is the meaningful difference between a Program, Project or Product Manager? When do we use a Scrum Master or Product Owner versus a Delivery Manager? If I have a Scrum Master on my delivery team, am I good? Do today’s Agile titles mean we’re doing things new and better? Are pre-Agile ideas less valuable? Are PMI certifications outdated while Scaled Agile certifications are actually the best solutions for our tomorrow?

I believe these are all interesting philosophical conversations we can have over a pot of tea, but not the most important problem to solve. We want to hire a great person, not a great bowl of word soup.

We want great people who predictably, repeatably deliver value in our teams, across our projects, in our companies, and with our clients. If we’re debating certifications and titles, let alone hiring based upon them, we’re discussing the wrong subject. We want people who illustrate themselves by their past and desired journey versus define themselves by their past alone.

The below attribute lists are our ideal target lists. Given everyone is on a journey, we’re looking for people who bring these attributes with them, are on a journey to attain them, or have the right attitude and aptitude to be taught.

1. Look for People with Healthy Behaviors

At the end of the day, our teams, projects, and clients will be a reflection of the people we hire. We want people who want to win. People who never quit. People who regularly bring out the best in themselves and everyone around them. People who will never stop yearning to become more today than they were yesterday and expect the same of everyone around them.

2. Look for Diverse Bodies of Knowledge Awareness

It is fine to be an expert in a body of knowledge. Even expected. However, to believe that body of knowledge will transcend industry, context, and time is small, limited thinking. We look for people capable of more than one thing; else our results will be limited by the one thing that person knows. Find people who pursue knowledge, have broad interests and are life-learners. If you don’t know what all of these things are, why you care, or when you would use them, get busy.

3. Look for Diverse Experience

There is value in experience. For a life-long learner, experience is the ultimate teacher. We look for people who have breadth and depth of experience because we like people with larger and larger experiential data sets upon which to reflect, learn, and apply their realizations.

4. Log Aggregation, Machine Learning, and Artificial Intelligence

Using one too many redundant and/or popular terms of the day, companies increasingly pursue the ideas of log aggregation, data lakes, data warehouses, and data cubes on a regular basis.

  • How do I get the data out?
  • How do I put it all in the same place?
  • How do I correlate, corroborate or otherwise discover patterns and relationships which reveal new ways of seeing, thinking, deciding and acting thereafter?
  • If I put all of my data in one place and start using machine learning to process, organize, and extrapolate meaning as my data set grows, how do I use it?
  • And, if I want an artificial intelligence (AI) to begin making decisions for me where it makes sense, how do I leverage that as well?

I submit to you that an exceptional delivery manager encompasses all of these things including data aggregation, constant learning, and an intelligent decision layer.

At the same time companies pursue these ideas in modern technology, they are overlooking these qualities in experienced Delivery Managers.

Look at the below picture. Consider that the knowledge, behavioral and experiential attributes are the ever-growing data pool of a great Delivery Manager. Consider that your Delivery Manager is your machine learning solution which continues to derive patterns and possibilities by constantly increasing the data pool with new knowledge while continually churning the data, relationships, realizations, and decision possibilities thereafter. Consider that your Delivery Manager becomes an increasingly valuable AI seeing, hearing, learning, thinking, deciding AND thereafter acting on your behalf.

A two-day “how-to-deliver” certification course will not get you, your Delivery Manager, or your company and clients where you want to go. It is only a blip in the data pool. A valid experience that led to specific acquired knowledge. A very small, singular, moment of data on a long journey. Do it anyway. And then do 10 more.

5. Do Your Job to Enable Exceptional Delivery Managers

No matter who you hire, all Delivery Managers will need to know your desired outcomes and any particular constraints that matter to you and your organization. Look at it as defining done (desired outcomes) and the parameters of the game (methods and tools).

Your company and teams need to know where they are meant to go and under what conditions they can travel and arrive there.

An experienced Delivery Manager will notice if you have them in place, if they are clear and achievable, and help create, modify, manage, and complete them accordingly. Their job is to see the entire company, not just the problem of the moment.

What does that look like? Let’s look at a snippet of a conversation between a senior leader at your company and an exception Delivery Manager being considered for hire.

Senior Leader at your company speaking: “Hello Janice. I’m happy you’ve considered ABZ Company for your next adventure. We’re currently a USD 50MM pharmaceutical company on track to be an 80MM company in the next five years. We have adopted Scaled Agile for our preferred technology delivery framework, love the Agile space, but need help becoming more educated, experienced, and successful along the way. Most of our tool-sets are modern, our folks have been training on many things in the last three years and we have clear goals we’d like achieved over the next 18 months. We’ve been having quality and compliance problems with our deliverables, and I’m not sure how we need to fix this using our current tools and methods. What are your thoughts?”

Exceptional Delivery Manager Janice: “It sounds like you are experiencing quite a bit of success regarding the company, as well as, cultural transformation. Those are both hard alone; but doing them both at the same time and well, says a lot about the leadership and people in this company. Impressive.

It is outstanding that you know where you are and where you want to go. And it is outstanding that you know how you’d like to get there using the Agile body of knowledge, new tools, and retraining your people for the future. Well done.

You mentioned you’ve been having challenges with quality and compliance. Of course, I have very many questions and cannot pretend to fully understand your company in such a short period of time. However, I wonder, since your company has adopted Scaled Agile to help with delivery behaviors, have you also introduced evolutionary ideas for the engineering and information security teams? In other words, while Scaled Agile is designed as a delivery framework, it is not itself, and it is not designed to be so, an engineering and information security body of knowledge. You have to look elsewhere for those things. Teach me about the engineering changes that have been introduced to date.”

You, as a senior leader, are continually faced with more questions than you have answers, and always looking for options and recommendations which lead to choices. If you don’t know something, you tend to look in places where the data pool is deeper and wider than you currently possess.

Look to and hire exceptional Delivery Managers. They are the embodiment of ever-increasing pools of aggregated data with the machine learning and AI you seek. Just like no software is ever done, so too is it with exceptional Delivery Managers. Yesterday was good. Today will be better. Tomorrow, better again.

I drink a lot of caffeinated coffee and tea. And I’m on airplanes a lot. Drinking coffee and tea. I’m making a commitment to write more articles in 2020 – and increase the number of speaking engagements at which I drink coffee and tea. It is material we discuss every day at Trility and with our clients. It is material that you may find helpful as well. If you’d like to keep informed, and even interact, please connect or follow me on LinkedIn. Or we can send you an email

We are also always looking for system thinkers to join us – those who can see the larger landscape and do the work as well. If this resembles you, email us


Gerard Forbes Joins Team

Trility Consulting® is proud to announce Gerard Forbes has joined the Trility team as Director of Business Development in Omaha. In this role, Gerard is responsible for business development, strategic and client partnerships in Nebraska. His focus is to build trusted relationships by understanding when and how our team can help organizations create predictable, repeatable, and auditable digital solutions – one iteration at a time.

Gerard Forbes, Director of Business Development in Omaha

A Proven Approach

Forbes relies on his diverse professional and technology background to help clients understand and define challenges and align services to outcomes that help those clients take leaps forward. 

“Gerard is going to be a great asset for Trility and our clients,” said Brody Deren, Chief Strategy Officer for Trility. “He has a great ability to meet clients where they are, understand both their business and technical challenges and opportunities, and help them find the best approach to solving their most critical problems.”

Gerard will leverage his experience working for a technology consulting and recruiting services firm, where he additionally played roles in leadership and corporate training in the consumer packaged goods and retail industries. He also serves an adjunct professor at the University of Nebraska-Omaha where he instructs business students on Leadership theory and application.

About Trility

Trility is a collection of value-driven advisors, technologists, and business people who have critical skills and experience to help clients win in the modern digital economy. We solve complex problems, help guide clients down roads they’ve never ventured, and offer solutions in Cloud & Infrastructure, Product Design and Development, Data Strategy, IoT, Information Security, and Operational Modernization.

Trility’s proven approach is to provide observations and recommendations along the way, presenting options for clients to iterate for the best, high-priority outcome. We never compromise on security and leverage our team’s full-stack expertise and ability to train your team to question security requirements from Day 1 and build with continuous delivery everywhere.

Interested in learning more?

Connect with Gerard Forbes on LinkedIn, email or call him at (402) 212-7835.