2 posts tagged with "Tools"

At liblab, we tackle complex engineering problems to build SDKs for our customers and their end users, who are engineers themselves. Our team's extensive knowledge in software, software-as-a-service solutions, and developer tools is critical to our success. Therefore, retaining our talented developers is a priority.

Why should you care about engineering culture?​

While it's often said that people leave managers, not jobs, it's equally true that engineers leave companies with poor culture. Engineering culture, shaped by the attitudes and experiences of software developers and team leaders, influences the working atmosphere. By understanding the importance of engineering culture, we can enhance the positive aspects and minimize the negative ones.

Practical tools for fostering a great engineering culture​

There's a lot of discussion about building a great engineering culture on the internet. However, I'm focusing on practical tools here. These are concrete steps anyone can take to improve their team's culture and their own contributions.

1. Coding style and standards​

Coding style is an aspect of engineering culture. It's not about specific preferences - we're not engaging in the tabs versus spaces debate! - but how coding style is shared across the team. Often, one "tastemaker" can influence the team's preferred style. If one engineer is the sole torchbearer, the implementation can seem arbitrary, and enforcing that style in code reviews with the wrong tone can alienate coworkers.

A coding standards document covers basic expectations like naming variables and functions, commit comments, and best practices. Creating these standards with feedback from the team fosters consensus and buy-in. Implementing a corresponding linting solution in the team’s IDEs and code repositories can clarify expectations and allow for early and regular corrections by the system, not a peer.

2. Developer tool choice​

Another aspect of coding standards to consider is allowing tool choice. Not every developer likes the same IDE - some even prefer a traditional text editor! Allowing engineers to choose the solutions they’re most comfortable with will improve their satisfaction and productivity.

3. Code reviews and pair programming​

Code reviews are routine tasks with a significant impact on culture. For engineers who don't pair on projects regularly, this could be their main professional interaction. Establishing a routine for code reviews ensures this important collaboration happens consistently. We recommend engineers spend time at the start of their day and after lunch on reviews to avoid a full-day wait for feedback. Alternatively, regular pair programming can reduce the need for code reviews since multiple engineers have evaluated the code already.

While experienced engineers analyze the code for style, functionality, and performance, every engineer can contribute. Less experienced engineers should be able to understand the code and changes. Asking for more information on a new function is a great reminder to include detailed comments! Seeing how others solve problems can spark new ideas and questions, leading to mentoring or collaboration. Participating in code reviews fosters relationships between developers, improving collaboration and culture.

4. Architecture discussions​

Architecture discussions are some of my favorite times working in software engineering. Analyzing a problem, freely exchanging ideas, and incorporating elements into a cohesive solution represent the team's collective experience. Experienced engineers are naturally inclined to solve problems quickly, but these sessions are also opportunities to mentor and develop less experienced developers.

Encouraging experienced engineers to speak last allows the rest of the team to work through the problem together. Making a single engineer responsible for the project and the final decision on technical matters encourages strong ownership. This approach can also encourage participation from less experienced engineers, since they know an experienced engineer is ultimately responsible for the design.

5. Design reviews​

Technical design reviews follow these architecture discussions. The responsible engineer details the proposed solution in a "request for comment" document, which the engineering team reviews asynchronously. If there are comments to consider, then a meeting is scheduled to discuss questions and collect feedback. This process gives every engineer a voice, promoting participation and an inclusive engineering culture.

6. Hiring​

Hiring is another area where we can influence culture. New team members bring their own experiences and influence, but how we select them also matters. We at liblab prefer a take-home style coding challenge that closely reflects the daily developer experience. We've extensively discussed and iterated the content of this test, ending up with tests that target each of our engineering teams' focus areas.

Creating the test, having coworkers take it for a baseline, and evaluating the results is an important part of engineering culture. It establishes a minimum standard for the team, and completing the coding challenge becomes a shared experience and a badge of belonging for those who join.

Conclusion​

Here are some practical tools for fostering a great engineering culture:

• Promoting coding style through tools
• Allow engineers to use their preferred tools
• Setting ground rules for engineering discussions
• Conducting inclusive design reviews
• Regular code reviews and/or pair programming
• Involving engineers in hiring practices

Anyone can adopt these practices within their own engineering team to enhance their culture. Teams should also experiment; what worked well for us at liblab might differ for your team.

If our commitment to a great culture sounds appealing, then come join us! We are hiring for a range of roles, and you can find more details at liblab.com/careers.

As engineers, we often prioritize scalability, elegance, and efficiency in finding solutions. We despise monotony, tedious tasks, and boring work that consume our time. It becomes especially frustrating when we identify a tool that can reduce effort and produce better results, only to be turned down by management. This article will guide you on how to effectively communicate your tool request to management, increasing the chances of getting a 'Yes' for your proposal.

You’re Not Asking The Right Way​

You may find it obvious why the tool you recommend is a great investment. It saves time, improves results, and allows you to focus on high-return activities for your organization. However, management doesn't always grasp these benefits. Why is that?

The reason lies in how you present your case. Management is primarily concerned with the organization's Profit and Loss (P&L). Their role is to maximize revenue while minimizing costs. When you propose a tool, simply highlighting time savings or improved output these don’t necessarily resonate. They are one step removed from what truly matters to management. Unless you can quantify the impact of the tool on P&L, management will perceive it as an "additional cost."

Show Impact on P&L​

So, how can we translate the "additional cost" into improving the P&L? It's actually quite straightforward. While there will be an initial cost associated with the tool, evaluating it in isolation is not a fair assessment of the P&L impact. To present the impact properly, you need to calculate the additional revenue generated by the tool or the opportunity cost of not having it. The sum of the additional revenue (Rev_gen) and the opportunity cost (Opp_cost) subtracted from the tool cost will quantify the impact on the P&L.

PL_impact = Rev_gen - (Tool_cost - Opp_cost)

Provided you can demonstrate that investing in your tool will result in a positive PL_impact (> 0), management should find it an easy decision to support.

How To Calculate P&L Impact​

Now that we know what needs to be quantified (Rev_gen and Opp_cost), let's discuss the general methodology used to quantify them.

1. Identify the input parameters required to calculate Rev_gen and Opp_cost.
   • Write down the expression that dictate the calculations for each parameter. Assumptions are acceptable and often expected.
2. Build a simple model (a spreadsheet, no LLM required 😉) to calculate Rev_gen and Opp_cost based on the input parameters.
3. Present the calculations in a straightforward and simple manner. It's crucial to show all the math. It should be laid out so simply, that even a middle schooler can follow the logic.

Example - Calculating Opportunity Cost​

In the following example we will show how we at liblab calculate the opportunity cost associated with building and maintaining SDKs for an API manually. This allows us to enable our customers to show that leveraging liblab’s products & services are a fraction of the cost of tackling the problem yourself (we assume a Rev_gen of 0, for simplicity sake)

Opp_cost = APIs * Num_SDK * Cost_build+maintain_per_SDK

1. Input Parameters

   1. APIs = Number of APIs your organization needs SDKs for
   2. Num_SDK: Number of SDK languages you need to support for your APIs
   3. Cost_build+maintain_per_SDK can be further broken down into:
      1. Cost_build/SDK: Engineering cost per SDK build
         1. Cost ($) / Hour derived from engineering salary
         2. Hours / SDK Build (assumption based on your organization's API complexity)
      2. Cost_maintain/SDK: Engineering cost per change and number of changes
         1. Cost ($) / Hour derived from engineering salary
         2. Hours / SDK Build (assumption based on your organization's API complexity)
         3. Update Frequency (assumption on how often your API changes)

2. Model calculating Opp_cost based on input parameters:

   1. The reason we want to put this in a spreadsheet model vs. just writing the equations and answers out is because it makes it easy for management to see the end result, if they don’t agree with one of your assumptions - most of the times this won’t change the decision on the tool but will help deal with any objections they may have.
   2. See models governing equations below:

   Opp_cost = APIs * Num_SDK * (Cost_build + Cost_maintain) per SDK
   Cost_build/SDK = Cost_hr * Hrs_build
   Cost_maintain/SD = Cost_hr * Hrs_maintain * Update_frequency
   

3. Present the Math Simply - Below is a screenshot of our liblab Investment Calculator

   1. This calculator depicts the investment needed by an average liblab customer if they are to build and maintain SDKs across 6 languages themselves for a single API.

As you can see, the cost of building and maintaining SDKs for our average customers exceeds $100K. Making the cost of liblab’s product and services a fraction of the opportunity cost, resulting in very good return and positive impact on P&L.

Conclusion​

To obtain a "Yes" from management for the tools you need, demonstrate through a model how they will have a positive impact on the P&L.

At liblab, we have created a calculator that helps developers articulate the cost savings of using our services to management. Not to mention the additional impact a better developer experience can have on their business (not quantified in our calculator).

If you're interested in receiving a free estimate of your annual API SDK investment, reach out to us via our contact form and mention "Free SDK Investment Assessment" in the message field. We'll respond promptly and provide you with a customized report breakdown, similar to the example above, tailored to your organization.