How do you balance tech and business requirements?

Both technical and business requirements are critical in product development. Customer & business needs vs. wants should be considered when determining the minimum viable product requirements. I have seen success stories where feeding customer value analysis back into the development process (as far up stream as you can get) can greatly increase the products likelihood of success in the market and/or intended application. This is true for both SW and Hardware product development. Bottom line: don't freeze your requirements until you have verified the value to both the customer and the business your supporting. The best way to do this is to solicit feedback early and often. Yes its more work, but well worth it in the long run.

It's more than just collecting requirements - it's about understanding how your customer benefits from these requirements. You'll need to ask questions - it's never as simple as "do this", "provide that". At times the requirements can be contradictory and you'll need to dig in and understand. Sometimes "requirements" come to you as a solution. Examine these carefully - often the solution is something that may work now but be a limitation in the future as it needs to scale.

Communication is critical. You'll need a plan and it will need to be communicated at several levels - from the highly detailed and technical to the high leveled and simplified view so that you can communicate effectively to your stakeholders. Agreement with the plan is required for collaboration and support at all levels. Once the plan is in flight regular communication to those stakeholders is necessary. It should communicate progress against key milestones, any dependencies you have, spend against budget and progress against OKRs. If the plan is complicated you'll need to roll out in phases to ensure business continuity if your changing systems dramatically, or seeking customer input on direction.

Agile development techniques allow you to break complex work into smaller, deliverable parts. If done well can be the difference between success and failure. Team size and makeup is critical. Having an agile mindset will keep you on the right path. Following the basic principles of agile and really doing them it's necessary otherwise you don't get many of the benefits of agile SDLC. As time goes on continually examine what's working and what isn't. Don't be afraid to try new things. If it doesn't work, fail fast and go again with a tactic. Too many teams get comfortable and don't ask the question of what can I do to make it better and then iterate.

As a leader of an engineering team the most valuable thing you bring is perspective. You should be the glue or the lubricant for your team, depending on what they need. If your team is very mature and skilled you mostly get out of the way after helping define the guard rails to help the team be successful. Empower the team to make decisions, the more experienced the team the less you get involved. Your primary role at that point is to remove roadblocks. Ensure decisions get made and keep the team moving. For a less experienced team you'll be more hands on - identify where the team needs your help. Empower them to make decisions that fit with their experience level.

As an engineering leader you should always have an evolving strategy for your space that aligns with the company and your own goals. Cloud first design, move to a dev Ops model, increase the maturity of your org by championing Event driven architecture, and so on. You will also have tactics - the shorter term things you are trying to accomplish. Ship a deliverable on time and quality, develop your team leads design skills, help your boss with leveling the experience level across their teams, and so on. You are constantly balancing the strategic against the tactical. You are always observing trends in the industry, reading articles on how to improve your team and space. Learning, learning, learning.

Being flexible and knowing the personalities involved as well as your own limitations are qualities of great leaders. Know how to set limits and being adaptive is learned or you will not learn and be left behind. Learn to identify what you can control and what you cannot. We have all seen managers who are technically excellent but are challenged on delivering the business goals. It's always a good balancing act that is achieved by doing.