IMG_0601.PNG


Have you heard of The Unicorn Project? It's the follow-up to the great Phoenix Project. As I said in my 2021 book review:

"what Kim did for Ops & DevOps in the Phoenix project, he has continued for product development in this work"

Both of these books use narrative to demonstrate the move to agile ways of working and devops transformations within an auto-parts selling business.

These five ideals are very helpful for looking at ways to enhance a technology practice.

---

Here's where I'm going to "think out loud" again. As I read these, I realized they'd make a better framing for how I've been approaching some challenges my team faces at work. I've been communicating with my manager using the perspective of "accountability without authority or responsibility", and while that's true, the Unicorn Project ideals might be an even better lens by which to view the problems.

Let me work through them to see what we are doing or could do in each area.

Locality and Simplicity

This is the core issue, as I've recently been thinking about it. My team relies on data, processes, instructions, and approval for almost everything from another team (and primarily one team). Work comes in from the other team, work goes back to that team. This disincentivizes problem ownership by either team, as things get "tossed over the wall". Further, because of the back and forth, there are steps that don't necessarily add value.

To solve these, we need to create local ownership and reduce waste & complexity. Instead of there->here->there work, we can improve this in one of the following ways:

  • here->here->there: meaning that my team sets the direction, rather than receiving it, but the other team still manages the result
  • there->here->here: meaning that my team still receives the direction, but has more capability to finish the work on their own
  • there->there->there or here->here->here: meaning that one team has full ownership for direction, results, and problems for an area of work

For us, the most appropriate short term answer is here->here->there, with a potential move eventually to a true locality where one team manages something all the way through the lifecycle. I've been advocating for this two-step approach, but now have a different way to talk about it.

Focus, Flow, and Joy

We have a culture of meetings. This is especially true for our New York office (where my boss and my peers are originally from). During covidtide, this has ramped up even further. Added to that, my team is working with a great number of stakeholders (often working with with many leaders and over 250 internal customers, each), has many sources of incoming requests, and encounters many "squirrels" caused by hot topics or VIP perspectives.

Altogether, those equate to very little time for focus or deep work. That results in less satisfaction and joy as people feel like they are constantly juggling instead of achieving momentum through wins.

We've got a few irons in the fire on this, too:

  • "No Meeting Wednesdays": we instituted this recently, and while not perfect (due to stakeholder meetings and increased interruptions from people who know we are "free"), it helps there be the chance for blocks of time for focus
  • "Ways of Working" agile alignment: I've been proposing that we get all our work visible under one mechanism, so that we can better manage priority, work-in-progress, etc. It would also help to have requests come in a common way, reducing interruptions. We've got buy-in now to get some agile coaches working with our broader org on a group transformation.
  • Using collaborative tools: Many interruptions can go away if we have standard means to keep one another up-to-date or make decisions. I'm helping push adoption of these ways. (Kanban boards instead of status meetings and inquiries, asynchronous work out of the same document rather than a meeting for committee-editing, decision-records and next-actions captured in writing, etc.)

Improvement of Daily Work

There isn't a lot additional to say here, as so much of it is dependent on the above two areas. If my team doesn't have much ownership of their work, nor the time to focus on changes, it's very difficult to focus on daily improvements.

Instead, I try to make up for some of this deficit by spending a lot of my time on this, looking for ways to help the team. Creating clarity. Creating or sharing resources that make things easier. Promoting the internal sharing of best practices, wins, and lessons-learned. Cutting waste. Eliminating blockers. Etc.

Psychological Safety

The idea of psychological safety is this: Team members have to feel that it's ok to speak up, that their concerns won't be dismissed and they won't be retaliated against. Team members have to feel that it's ok to learn, make mistakes, clean up after themselves, and grow; that they won't be penalized for trying something new. 

It wouldn't be appropriate to say much here (as it could affect psychological safety!), but I will say that I seek to promote psychological safety by being transparent, authentic, and non-defensive. I look to give opportunities for people to stretch themselves in a safe manner. I aim to make sensitive constructive comments in private and heap praise in public. 

Customer Focus

We can think about customer focus in two ways.

The first is the most important: the end costumer of the product or service. Do we know what they need, and is our work ultimately serving them? Or are we creating waste and doing pet projects?

The second is the internal customer, or stakeholder. This one is easy to overlook, especially if a team isn't used to thinking about having customers, which is an all-too-common occurrence in the technology world.

To help with this, what I do is to advocate for customer and stakeholder perspectives up front and every step along the way, both in my team and for the teams where we are the internal customer.

  • Who will use the product or service?
  • What do they need?
  • How does that inform our requirements?
  • Is somebody getting their perspective and feedback?
  • Do you need to get their buy-in for the solution?
  • Is there an easy way for them to give you feedback and see that you are doing something about it?
  • etc.

If your org has a product-owner type role, this helps a great deal!

---

I hope taking a look at these 5 ideals was helpful for you. If you've used them to examine some ways of working, tell me about it!

Originally posted at Hey World