I enjoy applying technical concepts that have been field-tested time and time again in the industry to other aspects of work and life. In my last blog, I did an investigation into applying the concepts of server load balancing with team management. While writing these blog posts, I started storing my ideas in a Google Drive folder, using a very basic versioning system to keep track of the ideas I had written and developed so far. I used simple text tags in the names to track the progress of each file.

[IDEA 2024-01-23] - Version control in life
[WRITTEN 2024-01-24] - [IDEA 2024-01-23] - Version control in life
[POSTED 2024-01-25] - [WRITTEN 2024-01-24] - [IDEA 2024-01-23] - Version control in life

Which brings me to the concept for this post: how can you apply the concepts of version control, commonly used for software engineering and complex documentation projects, to aspects of your everyday work and life to help you stay organized? Adding some simple methods taken from common version control methodologies can be useful in many different aspects of life and work. Take for example financial records, applying some basic naming conventions and versioning to your filing (whether digital or hard copies) can provide some much-needed ease of access to a set of information that can easily become overwhelming.

Travel Plans are another great example. Maintaining a versioned itinerary for your travel plans, with updated details, notes, and tracked changes to your schedule can help add order to what could otherwise quickly grow to be a chaotic experience.

So let’s take a look at some of these aspects of version control that are commonly used in engineering, and dive into how they can be applied in work and life.

Naming Conventions
One of the tenants of version control software is naming your branches, and this is a very useful concept to carry over to daily life, whether files and folders in your PC or your Drive. Adopting a consistent naming convention for your files and folders helps easily recognize what you’re looking for, and is a major boon when searching for something you can’t find. This could include dates, project names, or a combination that makes sense for you. Include version numbers or dates in the file names to easily identify the latest or specific versions, but try to stay away from using the “image_final.png”, “image_final_final.png”, “image_final_final_final.png” method. Standard versioning in software uses the Major.Minor.Patch scheme and this can be helpful for documents as well. For example, the file name image_1.0.3.png means that it’s the 1st MAJOR revision of the image, and 3 quick ‘patches’ or tweaks.

One thing to keep in mind with your naming is operating system compatibility. For most Mac and Windows users it’s not an issue, but for users who use Command Prompt, Powershell, Terminal, etc… certain characters like spaces can be annoying to work with. This is why you’ll often see ‘techie’ types use _’s in their file names instead of spaces.

Documenting Changes
Establishing a changelog for your projects or daily activities is crucial for tracking the evolution of your work and gaining insights into the decision-making process. Consider photo editing as an example. While adjusting color curves and contrast might become second nature during the editing process, it’s easy to forget the specific levels and settings used, especially when revisiting the task after some time. Personally, maintaining a change log and documenting my workflow has proven invaluable. Despite my initial confidence in remembering the exact steps taken for a particular result, the next day inevitably brings a blank slate if not documented. This practice serves as a reliable reference, ensuring a smoother continuation of tasks and avoiding unnecessary repetition when returning to a project after some time.

Time-Stamps
Think about keeping time-stamped notes or journals for personal and professional activities. This helps you review your progress and reflect on your experiences. Timestamps in your notes, whether written or typed, can be an invaluable tool in tracking changes over time and even just finding information quickly. Let’s use tasks and to-do lists as an example.

Having timestamps for when a task was added to your list (as well as potentially when a task was updated, completed, or simply worked on) can be a great tool to prioritize tasks and keep track of your progress. Consider the following task list:

Email Cheryl.
Newsletter.
Verify expense reports.
File TPS reports.

It’s just a simple bullet-point list of the things that need to get done. Odds are you’ve got at least three sticky notes somewhere in your office that look like this. But let’s try adding some revisioning and timestamps to our todo list:

Task                     Added          Started        Completed
Email Cheryl             [2024-02-20]
Newsletter               [2024-02-21]   [2024-02-23]   [2024-02-25]
Verify Expense Reports   [2024-02-22]   [2024-02-22] 
File TPS reports         [2024-02-23]   [2024-02-25] 

How does this additional information help? To start, having the date the task was added gives some quick information to help prioritize the items on the list. At a glance, you can see some of the timestamps that are well overdue. It also gives an easy way to see what has been started. Starting a task from zero can be daunting at times, simply knowing that a task has already been started can make it so much easier to dive in and get to work. Knowing that you have checkpoints along the way will help break down the work into more manageable segments (using sprints and agile in everyday life, maybe a topic for another blog?).

Using a task management system that allows you to track changes and updates gives some great flexibility for updating task descriptions or adding comments to provide context for modifications.

Some other applications of timestamping could include health and fitness tracking. Creating a timestamped log for your health and fitness routines can help you track changes in your exercise, diet, and overall health. This can not only give you valuable insights over time but can also be a tool to keep you on track and motivated. I won’t dive too deeply into this topic as there are many amazing health and fitness blogs out there that have far more experience and qualifications on the subject than I do. Take a look and see what’s out there, there are some great examples of how to implement ledgers and logs in your health and fitness journey.

Finally, consider learning and skill development – If you are in school or taking classes, I highly recommend adding timestamps and versioning to your note-taking regimen. Manage your learning materials using version control. Keep track of revisions to your study notes, learning plans, and skill development projects.

Backup and Recovery
Finally, lots of software these days keeps version and change history so that you can see prior changes and revert, but keeping a hard edit trail can be useful for more critical information at times, so I’ll leave you with this final point…

Hit the save button!

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.