The only constant in life is change, and businesses are no exception! Maybe its pivoting projects based on business needs, maybe it’s changing market conditions, and maybe it’s keeping up with your ever-changing, ever-scaling, customer demands. If you are in Engineering Leadership or DevOps you are probably all too familiar with that last one. Having experienced the customer growth cycle from the engineering perspective at many different companies of many different scales, I have recently been thinking a lot about what systems and practices worked well, and which ones I’ve experienced in the past that fell flat.

The concept of ‘scale’, even from the relatively narrow lens of engineering, can mean many different things: Writing code that is extendable, optimizing servers, load balancing, standards and practices for growing teams, and on and on. There is no end to articles and resources on technical topics like load balancing, auto-scaling, and optimizing resources to handle increased workloads and traffic. What interests me though is how we can take those technical methodologies and apply them to management and leadership concepts. All too often, SOPs (Standard Operating Procedures), and other three-letter acronyms, are developed by starting in a theoretical vacuum and then applied to practical situations. But there’s no reason why we can’t apply some of the hard-learned lessons from technical best practices and apply them to the world of team leadership and design.

Take load balancing for example. It’s a practice applied to servers to spin up new instances of your application (or microservices) when under increased user load, and then assign incoming users across your instances in a ‘balanced’ manner. It’s a way to keep up with extra load during high-use times. The same concept can be applied to technical teams when in high-volume development or crunch times. Think about it, your teams are working at their normal capacity, on regular projects, when suddenly a massive new contract requires a massive and quick ramp-up of work from engineering for a short period. Just like a massive influx of users on the system, the same principles of load balancing can apply!

Let’s look at the definitions that are needed when defining a load-balancing system for a server and then apply them to a team-based environment.

1) Thresholds and Capacity

Technical load balancing: Server thresholds. First, we define warning signs that a server (or infrastructure) is nearing capacity. This is usually a metric with increasing gates, and can sometimes be as simple as user count or CPU utilization triggering warnings at over 10%, over 25%, over 50%, etc… and then automatically causing our load balancing process to kick in at a specific threshold.

Team load balancing: Team capacity. We can apply the same principle directly to your teams by having metrics that measure their capacity. Luckily for us, there are already plenty of tools available to use such as Agile for tracking teamwork, capacity, and velocity. All we need to do now is define and apply thresholds that tell us when we are going in a dangerous direction and signs that a team is nearing capacity. When these thresholds trigger, we can kick into load-balancing mode.

2) Bringing in resources

Technical load balancing: Spinning up new resources. So what happens when the threshold is triggered and the server is running low on resources? In the simplest terms, it starts spinning up new resources to take on the extra load. As load thresholds are crossed, additional resources (whether that be new instances, virtual resources, RAM, CPU, etc…) are brought in and turned on, allowing the infrastructure to handle the increased load for a short period. Once the activity spike subsides, those resources are spun back down again.

Team load balancing: Bringing in additional support. So how do we apply the same lesson when one or more teams is nearing max capacity, or showing warning signs of being under extraordinary workloads? The same way the servers handle the extra load: bringing in additional support from alternate teams, or spinning up ad-hoc teams to begin to balance the workload between our new working groups. Sounds simple enough, but the real key is in the next couple of steps.

3) Load balancing

Technical load balancing: User allocation. This is where the real magic happens, once we have the resources in play to handle the additional stress that our infrastructure is under, we need to begin allocating the incoming load in a balanced way across all of the available resources. There are multiple methods of handling this from a technical perspective. Still, from a high-level overview it comes down to 1) putting incoming work into a queue 2) determining the next-up server to handle incoming (by lowest current usage or maybe as simple as round-robin), and 3) assigning the work to the next-up server. By now, you probably see where this is going.

Team load balancing: Task allocation. The same three steps can be applied to our teams as we spin up ad-hoc working groups or bring in additional resources. 1) Put incoming work into a queue, odds are you’re already implementing this via project management software or issue tracking software somehow (Jira, Monday.com, etc…). If you’re not, there’s no better time than the present to get started! 2) Use your teams workload metrics to track available resources to begin task assignments, or begin some time of output pipeline for your queue. 3) Standardize and implement your queue system with your teams so that they can begin pulling issues and triumphing over our work spike!

4) Documentation and SOPs

As always, the key to all of this is going to be documentation and making sure that all your teams are fully aligned and working together. Just like a DevOps team would document and clearly define each step on the load-balancing pipeline, it is crucial to document responsibilities and workflows the same way you would enforce documentation of code. This allows teams to scale quickly when necessary and not get caught in the trap of having to learn the ropes as they are brought into ad-hoc working teams and spin up new tasks. The better your systems and processes are documented and shared between your teams, the better equipped they will be to overcome challenges like these as they are presented.

In the ever-evolving landscape of technology, maintaining a robust and secure environment is paramount for the success of any organization. I’ve recently been going through the process of setting up the structure for a Security and Compliance (S&C) report and realized it would make an excellent topic for today’s blog post. So, let’s dive into one of the indispensable tools in your arsenal as a technology leader. In this blog post, we will explore the significance of S&C reports from a leadership perspective, delving into their role in enhancing technology awareness and decision-making within the engineering department.

As a manager or a leader, keeping your finger on the pulse of the security and compliance posture of your engineering department is crucial. S&C reports provide a comprehensive overview of the organization’s adherence to regulatory standards and security protocols. Think of it as a 360-degree view that provides you with a playbook for making decisions in the tech arena. By leveraging these reports, leaders can make informed decisions, ensuring that technology initiatives align with compliance requirements and security best practices.

In many ways, an S&C report is very similar to a traditional SWOT analysis: We uncover valuable insights that serve as Strengths, Weaknesses, Opportunities, and Threats (SWOT), but are specifically tailored for the CTO or leadership team, and in the context of the engineering department. This comparative analysis allows us to identify internal strengths and weaknesses, address potential threats, and capitalize on growth opportunities.

Security and Compliance reports act as a lens, uncovering potential threats and weaknesses in the technology infrastructure. By identifying vulnerabilities, we can proactively implement measures to mitigate risks and fortify the organization’s defenses against cyber threats. But that’s not the last stop on this train! We need to take the insights beyond just identification, a Security and Compliance report needs to provide concrete actions. From patching vulnerabilities to refining access controls, actionable insights empower leaders to take proactive steps in securing their technology ecosystem.

It’s not just about addressing risks though; a Security and Compliance report also highlights growth opportunities. By aligning technology initiatives with compliance standards, we can foster innovation and secure a competitive edge in the market. You might be surprised to find the synergies right there waiting to be leveraged as you dive into your engineering team reports. Just the act of bringing too many disparate sets of data into a single location reveals valuable insights into your team.

So now that we understand some of the value of a Security and Compliance report, how do we actually do it? Every company is going to have its own needs for reporting, so you’ll want to tailor your own S&C to your department’s requirements. However, here are some good recommended sections to get started.

Executive Summary – Always include an executive summary in your reports, it provides a plain English overview of the following report (which can sometimes get bogged down in technical information) and ensures that the critical points are displayed right at the front. Be sure to include any changes and initiatives that you want to highlight even if they are detailed later on in the report.

Department Overview – This section gives you an overview of the current team structure, growth since the last report, any project highlights and milestones, and key metrics that you would like to review.

DevOps and Infrastructure Security – Getting to the core dependencies of the report, be sure to include critical (and oft-requested) information such as recovery point and recovery time information for all critical systems. Also, take this opportunity to document departmental access controls and user privileges, these may seem obvious but having a paper trail of snapshots from each S&C report can be invaluable.

Cybersecurity – The ‘S’ in S&C is for security after all. Paying close attention to incident response and handling is a good idea as it’s often one of the most ask-after sections when working with 3rd party compliance. You also may find it of value to cover recent vulnerability scans and penetration test assessments.

Integration Partners and Third-Party Data Access – Who has access to your data and what are they allowed to do with it? Again, it may sound obvious in hindsight, but keeping a regular snapshot of this information can prove invaluable in the long term.

Recommendations – always include a comprehensive list of actions at the end of the report, after all, what’s the use of all this insightful data without any plan?

In conclusion, as a leader in tech, incorporating Security and Compliance reports into your toolkit is not just a necessity – it’s a strategic advantage. These reports empower you with the insights needed to navigate the intricate landscape of technology governance. From setting up and enabling your defenses to capitalize on growth opportunities, S&C reports are indispensable for steering the engineering department toward a resilient and compliant future.

Developing technical metric-driven Objectives and Key Results (OKRs) can be a major challenge in an operational environment that often aligns with downstream objectives such as sales and churn numbers. The role of leadership is pivotal in ensuring that the engineering team’s goals are tightly integrated with the broader company objectives, requiring a strategic and collaborative approach. Having gone through this process a few times now, I’ve run across many of the stumbling blocks and learned some strategies about key aspects to focus on when developing technical-focused OKRs for an upstream department like Engineering. Hopefully, you will find some of these helpful, whether it’s your first time developing OKRs, or you are looking to refine an already established process.

Understand your downstream objectives. Start by gaining a deep understanding of the downstream objectives. Engineering doesn’t exist in a vacuum of developing new features and fixing bugs, you need to understand the company as a whole. Deep dive into everything including sales figures, customer churn targets, and other key performance indicators (KPIs). Engage in conversations with leaders from sales, marketing, and customer service to identify their priorities and pain points.

Approach engineering as a supporting role. It can be too easy to think about the engineering department as the center of the company, especially in a SaaS business. At its core though, the role of technology, and therefore engineering, is to support the pillars of the company. Try thinking about engineering as a supportive entity for example:

• Sales make the deals – how can engineering provide them with the product they need to bring in new revenue streams?
• Customer support keeps the revenue streams alive – what can engineering provide them to enable the customers?
• Product drives the roadmap forward – how can engineering best utilize its resources to support the product team’s vision?

Fostering collaboration between engineering and other departments is a crucial step before OKRs can get started. Establishing cross-functional teams or working groups that include representatives from engineering, sales, and customer service can be a major help in this direction. This ensures that technical OKRs are developed with a holistic perspective, taking into account the needs and challenges of downstream teams.

Focus on the “why?” It’s easy to get caught up in what you want to achieve and start down the path of how you want to achieve it when developing OKRs. Take a step back and ask the “why” before getting started. Why are these my department’s goals and how do they support the rest of the company’s vision? The goal is to craft technical objectives that directly contribute to achieving company-wide goals. For instance, if the company aims to increase sales figures, the engineering team could set objectives related to optimizing the performance of the product, reducing time-to-market for new features, or enhancing the scalability and reliability of the infrastructure.

Collect input before getting started. A common pitfall when starting out setting up OKRs is to get the company objectives and start diving right into how your department can measure up. Stop, breathe, and take a step back. As an engineering leader, you have plenty of ideas of what you and your team can do but start by understanding how your peers are approaching the subject. Meet with your fellow leaders and align on what the OKRs mean to them and their teams. A standard engineering project starts with requirements elicitation, setting up your OKRs is no different. Finding out what your peers need from you and your team, and as much as what you need from them is a key first step before ever starting to write out your OKRs.

Don’t leave your direct reports out of the requirements elicitation phase either! Valuable insight will come from all angles, and it’s important to make sure that not only are the needs of the company represented, but the needs of your team as well.

Use measurable metrics. Break down each technical objective into specific and measurable Key Results. These metrics should provide a clear indication of progress and success. For example, if the objective is to improve product performance, key results may include reducing response times by a certain percentage or achieving a specific level of system uptime.

Strive for a balance between short-term and long-term technical goals. While addressing immediate needs is crucial, it’s equally important to invest in initiatives that contribute to long-term stability, scalability, and innovation within the engineering department.

Regularly review your OKRs. Your OKRs are not static, this isn’t a fire-and-forget one-and-done deal, they need to be reviewed regularly. Schedule periodic check-ins to assess progress, identify challenges, and make necessary adjustments. This iterative process ensures that the engineering team remains agile and responsive to changing business dynamics.

Transparent communication is key to successful OKR alignment. Ensure that the entire organization, from engineering to sales, understands the role of the engineering team in achieving broader company objectives. Regular updates and feedback loops contribute to a culture of shared responsibility and collaboration.

It’s critical to make mindful choices about your branching strategy when working in version control. As your application evolves and your team expands, the complexities within your code and the considerations for Continuous Integration/Continuous Deployment (CI/CD) become deeply rooted in the branching strategy you adopt. Whether you’re just starting development or a well-established team, it is always valuable to re-evaluate the methodologies in use and make sure that you are making the right decisions for your needs. Let’s explore some of the most common strategies that teams utilize in their development workflows.

One prevalent strategy is GitFlow, known for its simplicity and well-defined structure. In GitFlow, developers create feature branches from the Develop branch, and these branches are managed independently. Once a feature is complete, it’s merged back into the Develop branch. Periodically, the Develop branch integrates into the Master branch, marking a release point. Keeping feature branches isolated from each other allows for multiple parallel strings of development, with potentially multiple developers branching off each feature branch to work in parallel as well. The compartmentalization of GitFlow can be great for large and complex projects, allowing for many things to happen at the same time, however, for smaller team sizes or smaller codebases, it can sometimes be overkill.

On the other end of the spectrum from GitFlow is GitHub Flow. GitHub Flow offers a simpler alternative, especially well-suited for smaller applications. This strategy employs only the Master and direct feature or developer branches. Features are directly merged into the Master branch, emphasizing continuous integration and seamless releases. GitHub Flow is great for quick turnaround time and continuous integration and hotfixes since it foregoes the multi-step approach of GitFlow. However, while GitHub Flow facilitates a quick startup with its low barrier to entry and fast turnaround time, it may face scalability challenges when applied to larger projects. Once multiple features are in development in parallel, with multiple developers working on each feature, it can start to get difficult to keep your release process straight with so few set processes.

GitLab Flow emerges as a functional middle ground which was designed for specific use in GitLab. Drawing inspiration from both GitFlow and GitHub Flow, GitLab Flow was designed around the DevOps perspective, and can still be leveraged outside of GitLab when implemented mindfully. Despite its balanced approach, GitLab Flow hasn’t garnered as widespread adoption as its counterparts.

It’s worth noting that there are myriad other branching strategies, and very few organizations implement one of the mentioned systems straight out of the box without some adaptations tailored to suit their unique needs. These branching strategies serve as excellent starting points, providing a foundation upon which you can customize your workflow according to the specific requirements of your application and organization.

The choice of a branching strategy is a pivotal decision in version control, influencing how your team collaborates, integrates code changes, and delivers releases. As your project evolves, don’t hesitate to experiment and adapt these strategies to create a workflow that aligns seamlessly with the needs of your growing application and dynamic organization.

Developing a web-based application is a long and winding road. One of the first and most critical decisions that you may come across on that journey is choosing the right hosting service. This can be a daunting task as there are so many options available, such as dedicated hosting, virtual servers, cloud hosting, and gasp physical server racks. Despite (or because of) all of these options, it’s essential to carefully evaluate the choices. For the scope of this blog, let’s focus on the field of cloud hosting, specifically the ‘holy trinity’: Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP).

Amazon Web Services, or AWS, is one of the most widely adopted cloud hosting services for enterprise-level solutions on the market. It boasts an extensive range of services that cover the entire spectrum of application development, from storage solutions to security features to load balancing. AWS provides a one-stop shop for all your hosting needs. Finally, because AWS is so widely adopted, the options for integrating other DevOps infrastructure systems are virtually endless.

However, the trade-off with AWS comes in the form of an extremely high level of complexity. The sheer breadth of AWS services can be overwhelming for beginners, requiring a learning curve to navigate through the multitude of options and configurations. Additionally, while AWS offers robust services, its pricing structure can be intricate, leading to unexpected costs if not managed carefully.

Microsoft Azure is another widely used service, with its main selling point being integration potential with Microsoft services. Azure excels in seamlessly integrating with other Microsoft services, making it an attractive choice for organizations heavily invested in the Microsoft ecosystem. Compared to AWS, Azure tends to offer a more straightforward pricing model, providing clarity on expenses.

However, Azure does have its drawbacks. Some services on Azure may not be as mature or feature-rich as their counterparts on AWS, and while less complex than AWS, Azure still presents a learning curve for newcomers.

The third of the holy trinity of cloud hosting services, Google Cloud Platform (GCP), offers excellent integration with unique Google offerings like machine learning and data analytics suites. GCP is often considered more accessible for beginners compared to AWS and Azure. It sets itself apart with integration possibilities for unique Google offerings.

However, as your application scales, GCP’s simplicity diminishes, and complexities will quickly arise. Additionally, it’s important to note that GCP has a smaller (though plenty vocal!) market share compared to AWS and Azure, something that may potentially affect community support and third-party integration options.

The choice between AWS, Azure, and GCP will obviously ultimately depend on your specific project requirements, budget considerations, and the expertise of your development team, but there are a lot of pros and cons to weigh in the process. While AWS offers a comprehensive suite of services, Azure excels in Microsoft integrations, and GCP brings Google’s unique offerings to the table. Careful evaluation of each platform’s pros and cons will empower you to make an informed decision that aligns with your application’s needs. Always stay updated on any changes in services, features, or pricing, as the cloud hosting landscape is continually evolving.