Stephen Kawaguchi - Solution Architect at IBM

March, 2021 blog, twitter, linkedin

Disclaimer: I’m an employee of IBM. The views expressed in this article are mine and don’t necessarily reflect the positions, strategies, or opinions of the company.

Tell us a little about your current role: where do you work, your title and generally the sort of work that you and your team do.

I work at IBM on the Cognos Analytics (CA) for Mobile team. CA is a suite of business intelligence tools that provides powerful cognitive capabilities. It uses AI and machine learning to help prep data and suggest ways to manage and visualize data. For example, it can suggest visualization types based on the type of data provided. It features best-in-class analytics capabilities, such as reporting, dashboards, data modelling, and data exploration. CA also takes analytics further and uses AI to generate insights and predictions. Since it’s true enterprise software, it runs in on-prem environments as well as the hybrid cloud on IBM Cloud Pak™ for Data.

Our development organization includes somewhere around 300 developers. My main team fluctuates between 8 and 14 and includes interns, devs, QA engineers, and a dev manager. Our technical backgrounds vary wildly which has presented a challenge to our goal to create a cross-functional team. To compensate, I’ve made learning a central part of our team’s culture. We’ve had to learn and teach a wide variety of technical and business process topics. Myself and the senior developers have tried to bring our knowledge level to where the team is at in order to create a shallow on-ramp. So far, it’s worked out quite well and we’ve built a fairly cross-functional skillset across the team.

We also have an extended family that includes a product owner, a UX designer, and a UX Researcher. They help bring us closer to our customers, and are invaluable in ensuring that we’re looking beyond the code to the heart of the business challenges before us.

As far as the Staff Eng Archetypes, I was originally deployed to this product as a Solver. I was challenged to get delivery on track while ensuring that the move from an on-prem monolithic world-view to a cloud-native one was central to our delivery approach. I’ve played the Tech Lead role several times in my career, and while I do enjoy the ability to focus on execution in a limited scope, I generally get restless. I inevitably get curious about broader organizational technical concerns, and especially the overarching strategy and OKRs. In my last job I was a Right Hand and worked across multiple projects that were challenged. That has been my least favorite role because you never get to stay long enough to see how things really play out. I gravitate most towards the Architect archetype because it’s generally a good mix of strategy, technical, architecture, and mentorship. I also enjoy the variation.

I see my main responsibility to be ensuring the adoption of Lean, Agile, and DevOps practices in order to accelerate delivery while maintaining a high standard of quality. I typically do this through mentorship focused on code quality practices, providing coaching around Agile ceremonies to make sure that goal-setting and continuous improvement are part of daily work. I sprinkle in Lean business process improvement practices to ensure optimization of the whole workflow. I also spend a lot of time ensuring that our technical strategy is manifested properly in our architectural decisions. Finally, I also have to frequently get into the code myself to help along some of our longer-term strategic goals, as well as to continue my own learning.

On top of being responsible for our iOS and Android apps, our team is DevOps-capable and builds, maintains, and handles many of our own deployment responsibilities, and we’ve forged a close partnership with our SRE colleagues for the environments we don’t deploy to. My overarching goal has been to position the team to take advantages of the wealth of knowledge in the DevOps space for better delivery outcomes, and I’m proud to say that they’ve responded admirably. Our performance is exemplary within our product group.

Did you ever consider engineering management, and if so how did you decide to pursue the staff engineer path?

One of the reasons I joined IBM is because they have a robust process to become a Senior Technical Staff Member (STSM). We also have Distinguished Engineer and Fellow levels. Those are essentially executive positions for technical folks. I took this as a sign that there is a sophisticated view of how IBM fosters non-managerial growth.

IBM is massive, with somewhere around 350,000 employees, 100,000 of whom are technically-focused, and with tens-of-thousands of developers. The level of variance in the path to Staff Engineer is high. It’s mostly going to depend on the context of the group. We have levels of seniority but they are very fuzzy and I don’t think I’m the right person to attempt to explain them.

That said, senior-level talent is clear and present. I’ve never been part of a company that is so dedicated to creating mentorship situations, nor one that’s been able to present me with multiple mentors. I’ve had very few technical mentors over the years, but here I get to schedule regular 1:1s with multiple Distinguished Engineers and STSMs. This is a stated part of the responsibilities of the Staff Plus cohort, which is pretty cool. I’ve learned a lot about dealing with technical strategy at scale - something I doubt I’d be exposed to at a growing company.

My DE mentors were matched with me organically. One was part of my interviewing process and so has been there from the beginning. The other two were connections made by various bosses, who felt that my sensibilities and their’s would align. All have been wonderful at showing me the ropes, and being direct about challenging me to elevate my thinking. It feels very familiar to my early days when I was first being trained as a manager.

As a software engineer at IBM, your paths to seniority are varied. Technical excellence, hard work, organizational skills, and the ability to move others are all recognized and rewarded. A lot of it also comes down to whether there is actually an opportunity for promotion because it’s not tenable to simply have Staff Plus as something developers attain after x years. The demands on leadership, vision, communication, strategic skills, and the ability to align technology to business all go up very quickly as you move to more senior levels. The biggest challenge is in identifying the scope that a given Staff Plus engineer will cover and making a compelling case that a given engineer is the person for that job. So a Staff Plus promotion is under far more scrutiny than lower band promotions for good reason.

Can you remember any piece of advice on reaching Staff that was particularly helpful for you?

The best advice I’ve been consistently given by bosses, mentors, and trusted colleagues is that sometimes it’s better to beg for forgiveness instead of waiting for permission. This is my interpretation of what so many luminaries in the software world refer to as courage. This has been a hard lesson for me to internalize because I lean towards consensus as a way to make sure the approach is sound. But what do you do if consensus is clearly counter to strategic goals? Or when there is no consensus? That’s when you need to make the hard call. I’ve tried to reserve these for situations where our strategic goals will be completely compromised by indecision, bureaucratic inertia, or fear of change. I prefer to align on goals. Sometimes, you just can’t bring people around, even when they agree. So, you just go do it and accept the consequences.

How do you spend your time day-to-day?

Daily:

• For the equivalent of 1 day per week I participate in my main team’s Agile rituals.
• I try hard to code for at least 1 hour per day. That’s been elusive lately, but sometimes I’ve been able to code for 4 or even 6 hours in a day. It depends on need - for example, to provide the team examples of TDD’d code looks like, or to polish our authentication and globalization schemes.
• I spend ~2 hours per day reviewing code, talking strategic adjustments, pair programming, inspecting SonarQube for technical debt, having system design, pipeline planning, or architectural discussions, or doing other things related to the core product I work on.

After that it’s easier to talk about weekly:

• I run 3 - 4 tech coaching 1:1s each week.
• Every couple of weeks I either participate or lead an Agile or Learning guild session.

I also have a few key broad impact groups I participate in:

• I sit in on software craftsmanship and multiple regular dev transformation discussions that include multiple levels of technical leaders and management. These are fun because they are purely technical strategy. I enjoy seeing those strategies form and come to life.
• I have a regular working group of people trying to build out software engineering resources like a career guide and a software engineering playbook.
• I also talk with my network of mentor distinguished and staff engineers on a bi-weekly or monthly basis. This is sometimes therapy for me because I get great perspective from people with more experience and deeper knowledge. These are my favorite sessions because I’m exposed to role models.
• I’m part of my product area architecture guild where we discuss all manner of architectural issues, and where we conduct reviews. This is also technical strategy, but in much more technical detail.

The rest of my time is eaten up by a mishmash of responsibilities:

• Dealing with constant audits from quality, security, and performance testers
• Ensuring cross-collaboration is smooth across the 20+(!) groups that we need to occasionally interface with
• Multiple all-hands and AMAs with executives to get the big picture
• Dealing with support or direct customer enquiries.
• Helping totally random people that have gotten my name or my team’s name from someone.

Where do you feel most impactful as a Staff-plus engineer? A specific story would be grand.

My greatest contribution in my current role is transforming a struggling team of siloed devs to a fully Lean / Agile / DevOps-capable group that is trailblazing cloud-native workflows in our predominantly on-prem product organization. Our small group is at the center of a major transformation from many perspectives - from cloud-native, to nitty-gritty Agile practices, to Continuous Delivery. We’ve managed to cover a lot of ground in our 18-months together.

Even more excitingly: now that we’ve hit some major milestones and we have our CI / CD pipeline connected, we’re poised to scale our successes and help other teams take advantage of our lessons-learned and reusable functionality. This is what I’m most excited to see come to fruition!

That said, it took a village to raise our application, and we’ve had help from many other groups. The next phase of our work is to help others take advantage of our successes and build upon them. We’ve already seen some success in sharing our foundational work - it’s time for more tangible contributions from our side. This is where I hope my broad influence will come in handy.

Can you think of anything you’ve done as a Staff-plus engineer that you weren’t able to or wouldn’t have done before reaching that title?

I had a lot of these theories in my mind, but as we know, execution is much harder. Proving that I could lead a cloud-native team was a huge confidence-boost. It required rapid learning and pulling the team together to align them to clear goals.

More importantly, I used to be more hesitant and sought out validation of my approaches before committing. This job affords me much more discretion of my time than previous ones. I believe I’ve been able to make a much broader impact by doing so by figuring out who the people that move the organization are, and finding ways to align to their initiatives within my work.

Do you spend time advocating for technology, practice, process or architectural change? What’s something you’ve advocated for? Can you share a story of influencing your organization?

Yes, significant time. I’ve introduced these concepts to my team or organization through talks, workshops, POCs, or practical demonstrations:

• Agile Estimation
• Lean Startup
• Scrum
• FIRST Principles of Testing and effective unit testing
• TDD
• Software engineering principles (e.g. SOLID) and design patterns
• Blameless Post-mortems
• Value Stream Mapping
• More CI-friendly testing tools and approaches (Cypress, Consumer-Driven Contract Testing)
• Pair programming

What two or three factors were most important in you reaching Staff? How have the companies you joined, your location, or your education impacted your path?

A T-shaped skillset has helped differentiate me and have served me extremely well throughout my career. It may sound cliché, but the soft-skills have been just as important as the technical ones. You need both to move people at different levels, and to ensure you’re getting it right as a team.

Another factor is that I’ve been fortunate to ride the wave of multiple trends:

1. UX designers that could code were unicorns 20 years ago. That got me a great first job. In fact, I never worked as a designer. I was a coder right our of school.
2. Flash was hot at the time and that got me promoted really quickly because there weren’t enough people good at it to effectively lead teams of Flash devs.
3. I focused on really learning Agile just as it hit the mainstream.
4. I became a JavaScript developer just as the SPA craze began in earnest with Angular (I started using it the day it went 1.0.0).
5. I got to use React and Redux early on, just before they really took off.
6. I focused on DevOps just as it became mainstream. In fact, I had hit a crisis-of-faith in Agile. The way that Gene Kim et al. reinvigorated my passion because the way they’ve made it all come together resonates deeply with my own values. I’ve been running with DevOps ever since.

Finally, fluking into my first job at the BMO Financial Group Institute for Learning where I received several years of formal leadership and management training early in my career has been incredibly valuable. Not only has it opened up a lot of doors because I tend to be perceived as a team-builder, it’s helped me gain perspective much faster than I would have on a different path. I was pretty shocked to find out that the majority of new managers don’t actually get training, and so I’ve tried to make a point to find and share similar materials with other technical leaders as I’ve worked with them. Leadership skills like conflict-resolution, planning, formulation of strategies, communication, and understanding how to effectively manage other humans comes in handy no matter your number of direct reports. Actually, I’ve found that I’m more effective without having direct-reports because then I don’t get bogged down in HR overhead. I believe it’s helped me become a more nuanced and multi-faceted decision-maker far beyond the technical problems in front of me.

How do you keep in touch with how things really work as you spend less time on hands-on development?

I make a point of reviewing lots of PRs and taking on coding work in isolated areas myself. I also review code in the main line to avoid PR-myopia (the fractured view of the whole when you only review small slices of it).

To stay abreast of what’s going on in the industry, I take courses, do tutorials, read books and blogs, listen to podcasts, watch YouTube channels, and build silly little experiments in my personal time. Right now I’m more of a reader because I’m focused on trying to learn how to shift the trajectory of my product group as well as IBM. This is a new skillset to me, and so I’ve been fascinated to watch and participate in some of these efforts.

How have you sponsored other engineers? Is sponsoring other engineers an important aspect of your role?

An emphatic yes! I measure my success in their success. I was “raised” by my amazing early-career mentors to believe that your greatest personal success is how well you can elevate the people you work with. Over the years, I’ve learned the wisdom of that particular lesson. The most memorable highlights in my career have been when I see mentees succeed - whether it’s a promotion, a successful delivery that they’ve led, or simply just being comfortable in their own skin and confident in their abilities. It’s nearly as good as being a dad :)

I see sponsorship as active mentorship. So I’ve sponsored others by:

• Advocating for actual promotions with senior leadership
• Helping mentees identify the areas that they need to develop to progress (most recently using the Medium Engineering Growth Framework)
• Using 1:1s to help them plan and track progress against their career-development goals
• Providing my opinion as to how to present themselves to be more appealing for promotions
• Giving them transparent feedback on what I believe is impeding their growth or progression
• Helping them understand that their path forward will likely be unique to them, and that’s OK

What about a piece of advice for someone who has just started as a Staff Engineer?

I think this all the time to try to keep my ego in check and to put empathy at the center of what I do: We’re all standing on the shoulders of the giants that came before us. Stay humble and remember you’re being entrusted to elevate others, just as you yourself were elevated. It’s easy to forget about that with all of the distractions in our industry and the inevitable politics and pressure to succeed. Put ambition aside and treat others as you would like to be treated yourself (or maybe how you wish you had been treated). You’ll sleep better at night, and enjoy the kind of success that you can actually live with.

Next chapter: Mikhail Chernykh - Technical Lead at Indeed

Previous chapter: Aaron Suggs - Principal Engineer at Glossier

Book

If you've enjoyed reading the stories and guides on staffeng.com, you might also enjoy Staff Engineer: Leadership beyond the management track, which features many of these guides and stories.