Our industry is rife with trendy technologies such as clouds, microservices, digital experience platforms, AR/VR, and voice interfaces. We’re faced with trendy processes such as Agile, lean startup, and design thinking. And if you listen to some experts you would think that we have reached the final stage of advancement and these technologies and processes are all we need to be successful. Yet years ago our industry felt the same way about things like EJBs, UML, client server, structured waterfall and the like.

In their time, none of these were bad in and of themselves, but the collective hopping on the bandwagon that happens with each wave creates a potential for missing the actual benefit of the advances and often leads to organizations serving the means rather than serving their business. This behavior manifests in comments such as “that’s a bad requirement because it doesn’t fit our architecture”, “that’s not good storytelling”, “that design breaks the conversational interaction”, and “that’s not Agile!” In fact, we as an industry can become very dogmatic around the means as if that is our purpose rather than them merely being tools for solving problems. 

Said another way, all technologies, platforms, techniques, methodologies, etc. are simply tools or means for solving different kinds of problems. If we don’t know what problem we’re trying to solve with them, we won’t be effective.  

Peter Senge, in his book The Fifth Discipline, said “In the absence of great dreams, pettiness prevails.” Said another way, if we don’t have a measuring stick for checking the value of our work, all things are equal and decision making becomes arbitrary.​ 

Going deeper, if we decide we’re going to “implement a DXP”, “do Agile”, or “do Design Thinking” without understanding why, how do we know if we’ve done it correctly? In the absence of an actual business problem we’re trying to solve it’s hard to actually measure the value of what we’ve done. Which is why we as leaders should embrace the following principle:

In other words, we need to remember that we are solving problems for our business and for our customers, and that ultimately our approaches, be they process, technology, technique, etc., only have value when they achieve an end. 

In the digital world, and perhaps especially at large companies, team members can feel distant from the overall value of the company we work for, so we focus on what we can control to make our lives interesting. However, I believe that feeling that our work is well-aligned with the overall success of the companies we work for is a very rewarding feeling and provides the greatest motivation for our teams. 

Putting this into practice means understanding that our business needs don’t serve our architectures, our design methodologies, our internal approval processes, but rather that all of those should be wired to enable us to achieve something great.

Each of the approaches mentioned at the start are (or were) good at solving specific problems and were considered the modern approach in their time, but “modernizing” in and of itself is not an end. “Modernizing” doesn’t give us guidance into how to best leverage a digital experience platform, Agile or whatever the next wave will be. Understanding the end goals - be it organizational agility, horizontal scalability to minimize downtime at high loads, easy accessibility for the vision impaired, or some other need, will help us make better decisions on how to approach our work.

If we can understand when we should and shouldn’t use new practices, methods, and technologies, how they better solve problems than past approaches, and how to apply them to solve problems facing our companies, we will be able to make the right decisions.

Note: a different version of this article appears in 97 Things Every Engineering Manager Should Know

​A while ago I was asked the following at a conference: "I’ve had a mentor suggest that given my style is very direct to learn how to hone that into its most effective form. Is this a good idea?" My answer was not a direct yes/no because there are several things to consider. 

First, we need to have a good definition of leadership. I’ve posted this in the past, but my definition is:

Next we need to consider leadership styles. Finding a leadership style can be challenging, especially if you are just emerging from being an individual contributor, but even long-time leaders struggle with finding the right style. A leadership style should balance: adapting to what’s most comfortable for you, close alignment with your principles (which isn’t always the most comfortable!), and being the most effective with the people you lead. This can be a juggling act that has factors that can seem at odds with each other.

We can categorize leadership styles into three broad categories: Boss, Mentor, Servant. 

The Boss style tends to be more authoritarian: telling people what to do and how to do it, micromanaging, and things of that nature. On the positive side, there is often a lot of clarity with the boss type. 

The Mentor style tends to be more one of coaching: providing guidance and teaching as a way of instruction. At its worst, it can still have an underlying message of “there’s one way to do this - my way” and that is what needs to be taught.
​
The Servant style tends to be more one of empowering and enabling: setting goals with your team members, letting them reach success through their own means, and removing barriers to their success. At its worst, this style can be too hands off or mistaken for simply doing whatever your team members want you to do.

While I am a huge proponent of the notions of servant leadership, I’ve learned over the years that sometimes it’s not enough to set goals and let people run. Sometimes people need to be taught, and sometimes people need to be told what to do. The challenge is knowing when each is needed. I use the following principle to help guide:

Hopefully you'll find that a simple mantra to remember the tools ​in that order. Meaning, we should focus first on enabling people - making the desired outcomes clear along with any constraints and context and give them the autonomy to decide. If that isn’t working we should teach people how to reach those outcomes, and if they aren’t able to pick up on the learning we need to tell them what to do and how to do it.

So to bring it all together, I look at that initial question as “will being very direct enable me to influence individuals to effectively deliver durable results?”  The answer is “yes, but it depends on what you’re being direct about.” Your first priority as leader is to enable, in which case you should be direct about the outcomes they need to achieve (e.g. “handle 100,000 transactions per minute”). If that doesn't work, you switch to mentoring / teaching, where you should be direct about what they should do to reach those outcomes (e.g. “Think about elasticity and making sure you don’t lose any of the requests”). And when that doesn't work, you have to tell - to be direct about how they should reach those outcomes (e.g. “implement a queue and multiple processing servers”).