Category: leadership

Transform Your 1:1 Meetings: From Status Reports to Meaningful Conversations

Let’s face it—1:1s often feel like a chore. They can seem awkward, unnecessary, or even stressful, especially if they devolve into nothing more than a glorified status report. These meetings are supposed to be about meaningful dialogue, yet too often, they become just another checkbox on the to-do list. If you’ve ever found yourself reciting project updates that could’ve been sent in an email, you’re not alone.

But here’s the thing—when 1:1s turn into status reports, they lose their value. And that’s a big problem for several reasons:

  1. Missed Opportunities
    Turning 1:1s into routine updates means missing out on the chance to discuss your personal growth, career aspirations, or challenges that need attention. This time is carved out for your development and support. If you’re not using it wisely, you’re letting potential progress slip through your fingers.
  2. Lack of Connection
    When your 1:1s are all about status updates, you miss the opportunity to build a deeper connection with your manager. Understanding your manager’s goals and challenges is key to aligning your work with the broader mission of the team and company. Without this connection, you risk becoming isolated, working on tasks that don’t fully align with the bigger picture.
  3. Increased Frustration
    If 1:1s feel like just another meeting to get through, they become something you dread rather than look forward to. When these meetings lack substance, they turn into a time-waster, leading to frustration and disengagement.

So, how do you change the dynamic? How do you make 1:1s less cumbersome and more valuable for both you and your manager? Here’s how to flip the script:

Make Your 1:1s Count:

  1. Ask for What You Need
    Use your 1:1s to ask for the resources or support that will help you grow. Need career advice? Ask for it. Facing a roadblock? Seek help to get unblocked. Want to meet someone influential in your field? Request an introduction. This is your time—make sure you’re using it to your advantage.
  2. Understand Your Manager’s World
    Instead of just sharing your progress, take the time to ask your manager about their challenges and goals. What’s their biggest concern right now? What are they focusing on? Understanding what’s on your manager’s mind can help you better align your efforts with the team’s priorities, making you a more effective and valuable team member.
  3. Learn About the Business
    1:1s are an excellent opportunity to get a deeper understanding of the business. Ask about the company’s growth areas, the challenges it’s facing, and where your work fits into the bigger picture. Having this insight not only makes you more informed but also more strategic in your contributions.
  4. Seek Feedback Regularly
    Don’t wait for annual reviews to get feedback on your performance. Use your 1:1s to ask for continuous feedback. What are you doing well? Where can you improve? Regular feedback helps you course-correct quickly and ensures you’re always moving in the right direction.
  5. Discuss Long-Term Goals
    Use your 1:1s to discuss your long-term career goals. Where do you see yourself in a year or five years? What steps can you take now to get there? This helps ensure your day-to-day work aligns with your broader career aspirations and keeps you motivated.

For Managers:

As a manager, your role in 1:1s is crucial. If you’re not careful, these meetings can easily become stale and unproductive. Here’s how to ensure they stay valuable:

  1. Foster Openness
    Create an environment where your team feels comfortable discussing more than just their work progress. Encourage them to bring up their challenges, ask questions, and share their career aspirations. This openness builds trust and helps you better support your team.
  2. Share Your Perspective
    Be transparent with your team about your own challenges and objectives. This helps your team understand the context behind decisions and aligns their efforts with the company’s goals. Transparency also makes these meetings more engaging and less about checking boxes.
  3. Focus on Growth
    Your 1:1s are an opportunity to mentor and guide your team. Use this time to help your team members grow, providing the resources and support they need to advance in their careers. When your team thrives, so do you.
  4. Set Actionable Goals
    Work with your team members to set clear, actionable goals during your 1:1s. These goals should be specific, measurable, and aligned with both their personal development and the team’s objectives. Setting and tracking progress on these goals gives your 1:1s direction and ensures they’re driving real impact.
  5. Provide Regular Feedback
    Make feedback a regular part of your 1:1s. Don’t wait for formal reviews to give your team members insights into their performance. Regular, constructive feedback helps them improve and stay aligned with the team’s goals. It also shows that you’re invested in their development.
  6. Create a Safe Space for Honest Dialogue
    Encourage your team to speak openly and honestly in 1:1s. Let them know that this is their time to share what’s on their mind without fear of judgment. Creating a safe space for dialogue ensures that issues are addressed early and that your team feels heard and supported.

Conclusion:

1:1s don’t have to be a burden—they can be one of the most powerful tools for growth and connection in your work life. By shifting the focus from status reports to meaningful conversation, you’ll find these meetings become not only more productive but also more engaging and rewarding.

What strategies have worked for you in making the most out of 1:1s? Let’s share and learn from each other—drop your thoughts below! 👇

An Engineering Manager Challenge

This post came to mind while reading this post on LinkedIn, which is a share of this post by Kelvin Mai, and the follow up post Ted Neward made here. Read up on those for more insights into this topic.

Before diving into the details, it’s important to note that the criteria outlined here leave several questions unanswered, which could significantly impact the final decision. Factors like the specific nature of the projects, team dynamics, and long-term strategic goals are crucial and could sway the decision in different directions. That said, let’s break down the options.

Bringing on Two Junior Developers

Pros:

  1. Boosted Bandwidth: Two fresh faces mean more hands on deck to share the workload, increasing overall throughput.
  2. New Blood, New Ideas: Junior hires come with fresh perspectives and a ton of enthusiasm that can rejuvenate the team.
  3. Long-term Investment: Junior devs are like seedlings; with the right nurturing, they grow into valuable assets, contributing more as they develop.
  4. Flexibility: Juniors can be shaped to fit the team’s needs and culture, making them adaptable assets.

Cons:

  1. Boosted Bandwidth: Emphasis here though is on “throughput” above in the pros and not on committable, usable, and well written code you want and can use in the project. Increased throughput can be a negative, and IYKYK and can think of this as “induced demand” but for code.
  2. Training Time Sink: Juniors need a lot of guidance, which can be a major time drain for the senior members.
  3. Ramp-up Period: They won’t hit the ground running. Expect a learning curve before they start delivering at full capacity.
  4. Management Load: More people means more management. Even if they’re juniors, it adds to the admin overhead.

Hiring One Senior Developer

Pros:

  1. Expertise on Tap: A senior dev brings a treasure trove of knowledge and experience, perfect for tackling complex challenges and making strategic moves.
  2. Mentorship: They can mentor junior team members, leveling up the entire team’s skill set.
  3. Quick Impact: Seniors can dive in and start contributing much faster than juniors, thanks to their experience.

Cons:

  1. Higher Price Tag: Senior talent doesn’t come cheap. They’ll command a higher salary, impacting the budget more significantly.
  2. Cultural Fit Risks: There’s always the gamble that a senior hire might not mesh well with the existing team dynamics.
  3. Single Point of Failure: Relying on one senior dev for critical tasks can create dependencies, potentially leading to bottlenecks.

The “Do Nothing” Route

Pros:

  1. Save the Budget: Not hiring anyone saves money, which could be redirected elsewhere.
  2. Focus on Current Team: No new hires mean you can double down on developing and optimizing the current team.

Cons:

  1. Opportunity Cost: Leaving budget on the table means missing out on potential gains in capacity and productivity.
  2. Burnout Risk: Your current team might end up overworked, risking burnout and decreased morale.
  3. Stagnation: Without fresh talent, innovation can stagnate, and the team might struggle to keep up with growing demands.

The Decision

Let’s get real: not hiring anyone is likely the worst choice here. I know some would disagree in some situations, but if you’ve got budget allocated for new talent, use it! Even if the ROI isn’t immediate, it’s about positioning the team for long-term success. Hiring is an investment in the future—whether it’s two eager juniors ready to grow or a seasoned senior ready to lead and mentor. In this scenario, hiring one senior developer is the strategic move. You’ll get immediate expertise, mentorship for the juniors, and a stronger foundation for future growth. Let’s make that budget work for us and set the team up for success!

Addendum

This post attributed to leading me down the path to elaborate on staff and hiring details, including The Toxic Truth About Coding Challenges in Technical Interviews and then the elaboration on that post with The Reality of “Code Challenge” Culture Outcomes Among Large & Small Organizations.

Engineering API Governance

I’ve written this post to provide a detailed look at what a role around API Governance, or simply the functions of API Governance, would be centered around.

Why does this role exist?

An API Governance function or role would be responsible for overseeing the governance of APIs within an organization. It would center around ensuring that APIs are developed, implemented, and maintained according to established standards, best practices, and business requirements.

Here are the primary reasons why this type of work and role exist:

  1. Growing Importance of APIs: APIs have become the backbone of modern software development and integration. They enable different applications and systems to communicate and share data seamlessly. As organizations increasingly adopt microservices architecture and cloud-based solutions, the number and complexity of APIs they use grow significantly.
  2. Consistency and Standardization: In large organizations with multiple development teams and projects, maintaining consistency in API design, implementation, and usage becomes challenging. An API governance role ensures that APIs adhere to standardized guidelines, leading to better interoperability and reusability.
  3. Security and Compliance: APIs expose access points to an organization’s systems and data. Ensuring the security of these access points is critical to prevent data breaches, unauthorized access, and other security risks. An API governance role focuses on implementing robust security measures and compliance with relevant regulations.
  4. Efficient Collaboration: When different teams create APIs independently, they may not be aware of existing solutions or may duplicate efforts. An API governance function facilitates collaboration, knowledge sharing, and reuse of APIs, leading to more efficient development processes.
  5. Scalability and Performance: Proper governance includes performance monitoring and optimization of APIs. This helps identify bottlenecks, improve response times, and ensure that APIs can handle increasing workloads as the organization grows.
  6. User Experience: APIs are used by developers, both internally and externally, to build applications. A well-governed API ecosystem includes clear and comprehensive documentation, which enhances the developer experience and enables faster integration with APIs.
  7. Risk Mitigation: By setting up a structured governance process, organizations can identify and address potential risks associated with APIs early on, reducing the chances of costly issues arising in production.
  8. API Lifecycle Management: APIs have a lifecycle that includes planning, development, versioning, and deprecation. Proper governance ensures that APIs are maintained and updated according to their lifecycle stages, preventing the accumulation of outdated or obsolete APIs.
  9. Compliance with Business Strategy: API governance aligns API development and management with the organization’s overall business strategy, ensuring that APIs support the company’s goals and objectives effectively.
  10. Adoption of Best Practices: An API governance role stays updated with industry trends and best practices, continuously improving the organization’s API strategy and development processes.

Engineering API Governance Primary Functions

The API Governance function or role is responsible for overseeing and managing the governance of Application Programming Interfaces (APIs) within an organization. It ensures that APIs are developed, implemented, and maintained according to established standards, best practices, and business requirements. Here are some key aspects of an API Governance function or role:

  1. Defining API Standards: The API Governance team establishes and documents API design standards, naming conventions, versioning practices, security guidelines, documentation requirements, and other relevant policies. These standards promote consistency and facilitate seamless integration among different APIs.
  2. API Lifecycle Management: The API Governance function oversees the entire lifecycle of APIs. This includes planning and design, development, testing, deployment, monitoring, version control, and eventual retirement or deprecation when necessary.
  3. Security and Compliance: Ensuring the security of APIs is a critical aspect of the API Governance role. The team establishes security protocols, access controls, authentication mechanisms, and data protection measures to safeguard APIs and the systems they interact with. Additionally, they ensure compliance with relevant industry regulations and data privacy laws.
  4. Documentation and Communication: API Governance teams create comprehensive and easily accessible documentation for APIs. This documentation helps internal and external developers understand how to use the APIs effectively and provides details about their capabilities, limitations, and potential use cases.
  5. Monitoring and Performance: The API Governance function sets up monitoring systems to track API usage, performance metrics, and error rates. This data helps identify potential issues, bottlenecks, and areas for improvement. It allows the team to optimize APIs to meet service-level requirements and user expectations.
  6. Collaboration and Coordination: The API Governance role involves collaborating with various teams, including development, product management, security, and operations. Effective coordination ensures that APIs are aligned with business objectives and developed in a way that meets the needs of different stakeholders.
  7. Review and Approval Process: The API Governance team establishes a review and approval process for new APIs and changes to existing ones. This process ensures that APIs meet the required standards, security measures, and compliance before they are deployed.
  8. Education and Training: The API Governance function may conduct training sessions for developers and other stakeholders to promote best practices in API development, usage, and maintenance.
  9. Adoption of API Management Tools: API Governance teams often utilize API management tools to facilitate API governance tasks. These tools can assist in monitoring, versioning, security, analytics, and documentation management.
  10. Continuous Improvement: The API Governance function remains updated with industry trends and best practices to continuously improve the organization’s API strategy and governance approach.

In a large enough organization even these individual functions become individually staffed work. However, a single API Governance staff member often would be tasked with these items and would need to delegate and organize the priority of the various functions throughout the organization.

In following posts (which I’ll include here once they’re posted) I’ll write up some scenarios, from working as an individual contributor and leader (i.e. managing staff) as well as hiring for API Governance roles. I’ll get into the nitty gritty of how process, practice, and patterns can be used to elaborate on things like education, adoption of API management tools, continuous improvement and the many other functions.

With that, subscribe for updates, and you’ll get any new posts direct to your inbox! (check side bar for subscribing)

W Edwards Deming’s 14 Points

W. Edwards Deming, an electrical engineer, statistician (i.e. an AI expert!), professor, author, lecturer, and management consultant wrote some extremely prescient and wise things in his day. He became pivotal in how statistical analysis could be used to get better quality control. In the 1930s, and in turn these methods helped immensely in post- World War II Japan to rebuild it’s devastated economy.

Of the many things he write, one was a listing of 14 points. Which people today really ought to take a good long hard comprehensive read of. We routinely mess up and fail in so many ways by ignoring or just being oblivious to many of the lessons learned, and lessons Deming would teach us to avoid those failures.

  1. Create a constant purpose toward improvement.
    • Plan for quality in the long term.
    • Resist reacting with short-term solutions.
    • Don’t just do the same things better – find better things to do.
    • Predict and prepare for future challenges, and always have the goal of getting better.
  2. Adopt the new philosophy.
    • Embrace quality throughout the organization.
    • Put your customers’ needs first, rather than react to competitive pressure – and design products and services to meet those needs.
    • Be prepared for a major change in the way business is done. It’s about leading, not simply managing.
    • Create your quality vision, and implement it.
  3. Stop depending on inspections.
    • Inspections are costly and unreliable – and they don’t improve quality, they merely find a lack of quality.
    • Build quality into the process from start to finish.
    • Don’t just find what you did wrong – eliminate the “wrongs” altogether.
    • Use statistical control methods – not physical inspections alone – to prove that the process is working.
  4. Use a single supplier for any one item.
    • Quality relies on consistency – the less variation you have in the input, the less variation you’ll have in the output.
    • Look at suppliers as your partners in quality. Encourage them to spend time improving their own quality – they shouldn’t compete for your business based on price alone.
    • Analyze the total cost to you, not just the initial cost of the product.
    • Use quality statistics to ensure that suppliers meet your quality standards.
  5. Improve constantly and forever.
    • Continuously improve your systems and processes. Deming promoted the Plan-Do-Check-Act  approach to process analysis and improvement.
    • Emphasize training and education so everyone can do their jobs better.
    • Use kaizen as a model to reduce waste and to improve productivity, effectiveness, and safety.
  6. Use training on the job.
    • Train for consistency to help reduce variation.
    • Build a foundation of common knowledge.
    • Allow workers to understand their roles in the “big picture.”
    • Encourage staff to learn from one another, and provide a culture and environment for effective teamwork.
  7. Implement leadership.
    • Expect your supervisors and managers to understand their workers and the processes they use.
    • Don’t simply supervise – provide support and resources so that each staff member can do his or her best. Be a coach instead of a policeman.
    • Figure out what each person actually needs to do his or her best.
    • Emphasize the importance of participative management and transformational leadership.
    • Find ways to reach full potential, and don’t just focus on meeting targets and quotas.
  8. Eliminate fear.
    • Allow people to perform at their best by ensuring that they’re not afraid to express ideas or concerns.
    • Let everyone know that the goal is to achieve high quality by doing more things right – and that you’re not interested in blaming people when mistakes happen.
    • Make workers feel valued, and encourage them to look for better ways to do things.
    • Ensure that your leaders are approachable and that they work with teams to act in the company’s best interests.
    • Use open and honest communication to remove fear from the organization.
  9. Break down barriers between departments.
    • Build the “internal customer” concept – recognize that each department or function serves other departments that use their output.
    • Build a shared vision.
    • Use cross-functional teamwork to build understanding and reduce adversarial relationships.
    • Focus on collaboration and consensus instead of compromise.
  10. Get rid of unclear slogans.
    • Let people know exactly what you want – don’t make them guess. “Excellence in service” is short and memorable, but what does it mean? How is it achieved? The message is clearer in a slogan like “You can do better if you try.”
    • Don’t let words and nice-sounding phrases replace effective leadership. Outline your expectations, and then praise people face-to-face for doing good work.
  11. Eliminate management by objectives.
    • Look at how the process is carried out, not just numerical targets. Deming said that production targets encourage high output and low quality.
    • Provide support and resources so that production levels and quality are high and achievable.
    • Measure the process rather than the people behind the process.
  1. Remove barriers to pride of workmanship.
    • Allow everyone to take pride in their work without being rated or compared.
    • Treat workers the same, and don’t make them compete with other workers for monetary or other rewards. Over time, the quality system will naturally raise the level of everyone’s work to an equally high level.
  2. Implement education and self-improvement.
    • Improve the current skills of workers.
    • Encourage people to learn new skills to prepare for future changes and challenges.
    • Build skills to make your workforce more adaptable to change, and better able to find and achieve improvements.
  3. Make “transformation” everyone’s job.
    • Improve your overall organization by having each person take a step toward quality.
    • Analyze each small step, and understand how it fits into the larger picture.
    • Use effective change management principles to introduce the new philosophy and ideas in Deming’s 14 points.

I’ve reposted these here, as in some forthcoming posts I’ll be referring back to these and wanted to ensure that the reference was easily navigable to.

Losses & Gains, Tracking Task Switching & Thrashing

I take measurements and review statistical data on a range of topics to an extensive degree. However last year, pandemic year 2020, I dug into a few metrics to better tell the story about the damage task switching does to getting deliveries out the door. I wanted to answer one specific question, ideally with a measurable number.

How many projects, tasks, and other deliverables don’t get delivered because of task switching via corporate attention deficit hyper-action disorder?

CADHAD

If you’ve never heard of Corporate Attention Deficit Hyper-Action Disorder, welcome to the latest term I’m going to coin for use in this article. Possibly, I’ll use it in future articles, and refer back this one and for that reason let’s define CADHAD.

CADHAD – With a silent h this acronym stands for Corporate Attention Hyper-Action Disorder. Being specific, it’s the activity, anti-pattern, and syndrome of making activities within a business environment that routinely lead to the completion of other activities getting canceled, forgotten, or outright deleted. Usually after a thorough effort put into these actions being cancelled, forgotten, or deleted and through the switching, or thrashing of effort, extensive costs are spent over effectively having people do nothing.

CADHAD Metrics

Alright, back to answering the question “How many projects, tasks, and other deliverables don’t get delivered because of task switching via corporate attention deficit hyper-action disorder?”.

Here are a few metrics to get us started.

Actions Assigned, Started & Completed

DateStartedCompleted
January7611
February1233
March1311
April160
May110
June173
July65
August11
September4343
October3729
November5751
December2723

Projects Assigned, Started & Completed

To note, this is projects assigned to and at least 95% of the tasks assigned during the month for that project being completed equates to the project being marked complete for the month. If it’s less than that I leave it marked as incomplete. For example, if I get pulled off of tasks for project A and get put on tasks for project B, and because of that neither all the tasks for A or B get completed, that’s 2 projects started or continud for the month and zero finished.

Another important caveat, if a company is efficiently organizing their projects and efficiently utilizing their labor resources – i.e. their programmers – than this would be a 1 to 1 number, anything less than that means there are significant restarts and changes occuring that are significantly damaging effective utilization of people and resources. The TLDR, without a 1 to 1 metric the company is effectively burning cash.

DateStartedCompleted
January00
February60
March63
April00
May11
June11
July10
August11
September44
October44
November44
December55

Alright, so here are two sets of data. Let’s talk about what each tells us about the story of thrashing. The first part of the year, January through August of 2020 I was at one company – we’ll call it “Databases R’ Us” and the second part of the year I’ll call the company what it is, which is Hasura.

A Story of Thrashing

At Databases R’ Us I had joined a team that had numerous projects and tons of actions to get completed. Initially in January was a reset month, and it was, contrary to what the metrics for January tell us, a really productive month. No new projects were started, just preparation by closing up and finished actions or deleting actions. Which even though it doesn’t tell us a lot it does show one thing, there were a lot of actions that were entirely dropped. Of the 76 only 11 were wrapped up and completed. The reason, the previous months had left the team with a lot of technical debt that effectively just got ignored and the actions associated with paying that debt just got deleted.

The next month, Feburary starts to paint more of a picture of the significant levels of thrashing that were occurring. New projects were setup and planning had been done, totalling a massive 123 actions and 6 projects. I was ready to go, the team was pumped in that first week. However by the end of the month one can see that the level of thrashing immediately led to a massive failure of projects and actions to be completed. A caveat I have to add, is this is measuring a systemic failure, which is important to note because I could be messing up things myself but as we’ll see later I can also deliver robust solutoins when the systemic failures aren’t dragging projects and actions into the dustbin of oblivion. February was a rough period of time for the systemic completion of projects and actions that needed done. At month end, a miserable zero projects could be considered to have had their actions completed, and only 11 overall actions were wrapped up.

March rolled in and things improved, thank goodness, I needed the morale boost to be honest! 3 of 6 projects where brought to completion with their respective tasks completed. Bring the actions down to a very reasonable 13 actions to complete led to 11 being completed. An excellent ratio for task completion.

The next four months brough actions and projects into a varied mix of misdirections and failures mixed in with a few successes. Overall the subsequent 4 months Databases R’ Us improved efficiency of systemic delivery to about 50% or so. Not good, but much better than the January and February time frame where everything was a vast systemic failure that largely led to teams delivering on things that effectively didn’t get delivered to product or customers.

August wrapped up my work with Databases R’ Us with final delivery of a project and my departure. A fun time, and a great example of systemic wins and systemic failures around a company delivering or not.

Enter Hasura

I joined Hasura in October, taking a month in September to knock out some of my own personal projects and action activity. As you can see, of the things I planned and started with eventual completion I knocked it out of the park that month. In October, starting with Hasura that streak continued. October had a solid score of 4 projects started, 4 completed and 37 actions started and 29 brought to completed. Not perfect, but really good for just starting out at a new company – when so much time actions linger a bit longer just because one is still setting up their accounts and other requisite but not company useful work toward product or services advancement.

November and December continued that streak, 4 of 4 and 5 of 5 projects respectively. Even though December is often a really dead month for advancement of projects and actions to complete, in 2020 there were a solid bunch that I got into and knocked out. It provided me an excellent win upon new years! Even the actions completion ratio was really good.

Lagniappe Comments

2020 was a strange year, considering the pandemic changes and related characteristics of life itself this year. To compound the intricate complications of 2020 my son was born and I took a chunk of leave in the September and October time frames. Even with this major life event occurring I was still able to – even while taking care of a vast array of baby duties – contribute and knock out work and contribute systemically on a number of level to various projects. So much so, aside from the obvious leave, I’m proud that I went to bat at work at near 100% level even in light of all the pandemic and newborn complexities!

Additionally these were new metrics I had decided to measure and the implications behind them are still a bit hard to describe just from the numbers. Even though it does show the story of the year, it doesn’t really dig deep into where and how the task switching – AKA thrashing – occurred or the end result losses from that outcome. Only that it merely happened. This is something where I need to figure out further metrics that could show how, why, where, when, and what occurred that led to these metrics.

At some point I’d love to work on enriching this story through further data collection and figuring out the who, what, where, when, why, and how of the stories the data is meant to tell. Even more so, I’d love to work with others to brainstorm and figure out how to determine what telemetry should be used to provide this richer insight. If you’re interested, I’m available via the Twitters @adron and also you can directly mesage me here.

Summary

The wrap up is, the year definitely involved some significant thrashing that led to projects derailed and action items deferred, deleted, or otherwise thrashed on and left as waste. But the year also led to some striking counterbalances to that with 100% of projects getting worked on and delivered, with an excellent ratio of actions getting completed.

References