Why Being A Hands-On EA Leader Matters

Navdeep Singh
5 min readOct 10, 2021

Enterprise Architect (EA) leaders often get a bad reputation and are labeled as being “ivory tower”. This usually results from being out of date with technology and modern practices, not being able to get deep into solutioning & engineering, pushing heavy governance and policing, and being too theoretical with little to no practicality. Let’s face it, if you were a business leader or in a delivery team experiencing this from your EA leads you’d say the same.

Highly effective EA leaders are able to influence, lead others, solve complex problems, and communicate at all levels in an organization. Today’s business demands require EA leaders to be able to define strategy, establish and drive implementation of modern architecture patterns, and bring in new technologies to keep organizations at the leading edge and highly competitive. They are at the forefront of transformational initiatives providing thought-leadership and working alongside agile delivery teams from start to finish. A mix of highly developed soft skills, broad technology skills, complex problem-solving, and the ability to go deep are core competencies needed by today’s EA leaders to meet these demands. Let’s talk about what the “ability to go deep” means, why it’s important, and ways to stay hands-on as you advance into senior architecture roles and leadership.

Don’t Talk Fluff, Do Stuff

EA leaders who are able to go deep can roll up their sleeves and get into the software layers at design and code levels. It means they understand the details of how technologies work, how to implement modern patterns, and can be hands-on leading complex problem-solving and solution design while factoring in scalability, resiliency, and security. They are experienced with modern software engineering principles, patterns, and practices including agile, microservices, CI/CD, DevSecOps, and understand how the guidelines and standards they define impact the way software is designed, implemented, and managed. These skills don’t come overnight, they are progressively built over time through experience and must be maintained to keep up with the ever-changing technology landscape so EA leaders can engage at all layers to define and connect strategy to execution.

Be An Engineer First, Architect Second

Starting my career in software development, I’m fortunate to have advanced into EA taking on various roles. My ability and natural inclination to go deep stemmed from my software development and engineering background and as I grew into architecture leadership positions I immediately saw the necessity of these experiences in my daily activities. Regardless of the role, the need to have these skills never diminished. In fact they became more important as my scope increased, the business problems grew more complex, and I found myself being a part of digital transformation and modernization initiatives.

Modern EA leaders must recognize the importance of engineering skills and their connections with on-the-ground architecture activities. The solutions they define need to be comprehensive, defining both the “what” and the “how”. They need to be pragmatic and practical, going beyond theory to a hands-on level. In other words, it requires being an engineer first, architect second. Architecture skills are built from hands-on engineering experience and together form a combination essential for today’s EA leaders. Having an engineering mindset will drastically change how you approach architecture, enabling you to identify and manage business risk and technical debt, help as you engage with and lead others, and power your ability to drive strategic architecture down to software design and implementation.

Keeping the Engineering Skill

The reality is that keeping the engineering skill and mindset can get more difficult as you move into higher level roles and take on more responsibility. As with any other skill, keeping these current and at a deep level requires continuous use. There are many opportunities around you offering the ability to stay deep and, depending on your environment, some may work better than others. Below are several which I’ve adopted over time that have become regular activities in my professional life as an architect:

  • Be a life learner, learning new frameworks, methods, patterns, and solution approaches. There are no shortages of online classes, books/tutorials, articles, and certifications you can take. Be sure to pair any conceptual topics with concrete examples showing design and implementation level details. Code at home, over lunch (or after hours with a work group), and set aside time during your work week for training and development. If you’re the type who needs structure, keep a personal development plan with milestones to help track your progress. Keep what you learn primed and ready to use at a moments notice when the right business problems arise.
  • Participate in hackathons to put your coding skills to work in a casual atmosphere and exercise your creative thinking/problem solving skills. You’ll meet many bright people with whom you can exchange ideas and talk shop. Hackathons can be in the workplace or externally sponsored. Both are perfectly suitable as long as you get to exercise your mind and put your hands on a keyboard.
  • Teach through a formal university, online, or informally via a brown bag/lunch & learn/internal training session. If you do something within your organization create regular occurring sessions and foster collaboration by inviting others to also teach. Keep topics detailed, hands-on, and relevant to your organization.
  • Wear multiple hats at work and stay close to delivery, whether through a formal rotation or informally by helping with implementation. Take on a role with a product team where you lead solutioning and stay through implementation. This is a favorite of mine because there’s never a shortage of teams needing help and opportunities where you can step in to fill a gap. Lead POC’s, leveraging them as a way to create reference implementations for new architecture patterns which you can use elsewhere.
  • Get involved with innovation efforts, where you get to be hands-on evaluating new and emerging technologies, frameworks, and tools while developing scalable solution designs to address tactical business needs. You’ll be able to find and attack very complex business problems which require out-of-the-box thinking and creative solutions.

Wrap Up

An engineer has a deep understanding of how to use technology and design software to meet business needs; an architect can design highly scalable and resilient solutions, solves complex problems, defines technology strategy through execution, and influences leadership. Being an architect requires a foundation of engineering skills and mindset. Modern EA leaders must establish a norm where these skills are maintained and put to use regularly as a part of their architecture responsibilities.

Engineer your architecture, don’t just draw it; all architecture is engineering but not all engineering is architecture. Lastly, remember that architecture is not a noun, it is a verb.

Originally published at https://www.linkedin.com.

--

--

Navdeep Singh

Distinguished Software Engineer & Architect @ Walmart Global Tech. Do good, be good, the rest will fall in place.