Are you a brick layer?

“A man comes across two men laying bricks. He asks the two what they are doing. One says “I am laying bricks”. The other says, “I am building a cathedral.” – Anon (story contained within “Disney U” book.)

Seems like an odd intro to a blog post, right. But hopefully I can shed some light on my theme. A lot of my thoughts recently have centered around employee engagement, not just in what they do, but with other people within the organization about what they do. This story demonstrates in a very small way how one worker perceives what he is doing in a very small scope to the overall work. The other sees his work as integral to the accomplishment of the end value goal at hand.

So this got me to thinking a lot about this as this story, as odd things sometimes do, resonated for me personally. When I look across the vast landscape of the organization of which I am a part using this context, I began to see things in a different way and wondered if individual people see what they do in the context of the sole functions they perform as just “what I do” or do they truly understand how what they do contributes to many other aspects of the end business value goals, even within groups in a departmental level.

How do I impact something else …?

I started thinking about terms I hear in my organization (hence the title of this post) and if they adequately convey the value role that these groups play and the broader impact they have. I’ll give a few examples (mostly in relation to software products development, which is where my direct leadership lies) and see if I can illustrate what I mean.

Service Desk – The group that provides support for both internal and external products as well as perhaps hardware trouble shooting. This feels very self contained like “brick layer”. What is we considered our service desk staff as “service partners”? After all, they are the frontline of engagement to our end stakeholders using a product. Are they not a direct partner to us and what we do?

Should we not educate and prepare them to provide the highest level of customer service for products to create the best experience possible? What is the shaped perception of the overall product itself if the end stakeholder (possibly in crisis at the time as they need to get something done) receives a poor customer service experience? They are partners and should understand this and we should treat them as such. To not prepare them adequately through to provide the best customer experience through product and support knowledge is ultimately doing a disservice to the difficult creative work that turns ideas, design and shuffling bits and bytes into a product.

Operations – The group that keeps our infrastructure up and running and maintains the overall structural health. Are they a partner? Of course they are! Without them, we would have a line of customers stretching in queue as far as the eye could see because the developer says “it works on my machine”.

From people that know me well, I am often apt to say “a software product that cannot be deployed is useless as it brings no end value”. Even if it works perfectly in a development environment, if it cannot be deployed with quality and stability into a production environment so that people can use it, what does it matter how it works locally?

I have been so excited to track the development of a more dev-opsy type approach that I see people experimenting with that begins to truly solidifying this partnership and as a result using the idea of runbooks and support tools we are beginning to see more service partners have the ability to better assess the state of a product (which in turn allows them to give better information to customers and often resolve issues at a lower support tier giving more immediate service and therefore a better customer experience).

Database – The group that may provide a wide array of data services from design to tuning to database support and upgrades. Again, a partner. Yep.

In my environment, which is a larger scale service enterprise, the backend of the a product is highly important as it contains the data for which the business needs to store to complete a given business function. It also ensures that we are making use of existing data sources as opposed to replicating silos of data whenever possible. They are often a partner to creating end repositories of data at rest that create an enterprise or external view into data for insight from visualization or analytics. Any product we build without this group in my environment, unless it is perhaps a small functional tool, would be devoid of a core component of what we do.

Do we engage them as partners when we consider data designs or do they partner directly with us in this effort? Do they understand what choices we may make in terms of thinking about data design and do they sufficiently understand how the data design supports the application so they can respond efficiently under failure or need for ETL or abstraction?

Product Management – This group is probably the most engaged partner (or easily identifiable) in what we do as they are the pipeline for us to the end business needs. So how are they a partner? Without them, we would be “guessing” (even if intelligently and perhaps based on metrics) what the end stakeholders want. It would require us to not only discover the “what” of need but also to derive the “how” of getting the end value.

So it is imperative that they understand and communicate the need of the business through whatever means possible to the team for shared and unified understanding. This may mean that they have to utilize partnerships that they have developed in gaining that understanding to help communicate this understanding as well as bring the end stakeholders in as partners to the overall team as a whole to understand roi, criticality of function and how the end business unit may be a partner to the overall organization in achieving their end mission value goals.

Leadership – The people who should be setting overarching goals and focus at an organizational level and ensuring the support of those team members of which they maintain organizational oversight and healthy, happy, growing and productive.

I often get very disheartened when I hear line level people say “leadership or management doesn’t understand what we do” and it is in the context of some random edict that is being passed down for the good of something or other.

As leaders, there are some fundamental truths that you should understand by now:

  1. You will not please everyone. Any overarching decision made will not please everyone it impacts. That is just the way it is. If you build you organization to be flexible, open to experimentation and accepting of failure then you will likely have people open to try something if they feel the culture will listen to feedback in a reasonable horizon.
  2. If you are trying to control isolated poor behavior issues through a universal edict, get out of leadership today. This role is not for you. Being aware and responsive to issues is a core component to leadership but if you are trying to handle bad behavior of one or two folks by a global “rule” you are likely harming your culture. Address the problem with the problematic. Create a culture that can have open conversations when people perceive a problem and allow them to discuss it and give them a clear course to escalate.
  3. Accept the fact that you do not know the job that all of your employees do (even if you did that job before). If you want to know how someone does what they do, go have a conversation and ask them to enlighten you. And if you did that very same job before, likely you know how you did it; not how they do or how things may have changed within that particular role. You are a leader now. You have to gain and cultivate a new set of skills, which means you have to release previous ones most likely. Hire well, train well and trust your people and ask them how the role works. You may find that even though they do it differently it works even better than when you did it.
  4. Being a leader can often be a lonely existence. Leading and making leadership decisions are sometimes difficult and often are rooted in a larger purpose to the organizational health as a whole. Being firmly placed into situations where you have to determine how to “prune the weeds to protect the garden” or have to stand your ground to protect a value, purpose or team and become unpopular outside of your group carries a lot of heat to shoulder sometimes. But just like I was in school and struggled with mathematics, I had an instructor tell me I had to lean in and put in the effort as “math is hard”, leadership is the same and often you have to bare the burden to make the call as you are focused on the wall and not every brick

I do not say these things to infer that I do not have the deepest care and concern for each and every member of my group, I truly do. They are my daily inspiration of a creative force that takes ideas and turns them into solutions, however, I have to be conscious to step out of their way to meet this challenge and do so with intention and purpose. I would do anything I can for each and every member of my teams within my ability, however, I also have to be broadly aware of the organization as a whole.

So take a moment and ask yourself and consider your teams … Do they focus on the brick or the catherdral? If they do not see themselves as a part of something larger than what they do, I challenge you to get busy and help them see this connection.

As always, go forth and do good … and stay agile while doing so!


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s