Category: Leadership

The Engineer/Manager Pendulum

I am so happy I tapped on Episode 27 of the POPCAST this morning. And so glad Dan interviewed Charity and especially the focus of the podcast: her post about the “Engineer/Manager Pendulum“

I quote:

The best frontline eng managers in the world are the ones that are never more than 2-3 years removed from hands-on work, full time down in the trenches. The best individual contributors are the ones who have done time in management.

and

And the best technical leaders in the world are often the ones who do both. Back and forth.  Like a pendulum.

and

That’s one of the only ways you can achieve the temporary glory of a hybrid manager+tech lead. This is an unstable combination, because your engineering skills and context-sharpness are decaying the longer you do it.

I have been on my latest hybrid manager + tech lead gig for a few months shy of two years now – it’s not the first time for me by any stretch. It was incredibly validating to hear this swinging back and forth that I do as NORMAL.

The article concludes correctly:

It isn’t a promotion, so you don’t have any status to give up. Do it as long as it makes you happy, and the people around you happy. Then stop. Go back to building things. Wait til you get that itch again. Then do it all over again. <3

Photo credit

Engineering “Smell”

In software development, a phrase that gets used frequently is “code smell” – referring to an “odor” that code has or develops due to poor initial design or inattention to refactoring during continued development or maintenance.  Hallmarks of “code smell” include things like copying and pasting blocks of code instead of refactoring into callable functions, classes that have or develop multiple responsibilities, overly broad interfaces, and so on.

I think engineering departments can have smell too. Hallmarks of engineering smell include:

  • teams that develop processes, tools and frameworks with no expectation of coordinating efforts with other teams; effort is duplicated and uneven; autonomy and flexibility are valued much more highly than collaboration and long-term efficiency
  • teams are made responsible for maintaining more active products than they have resources for; the business comes to count on heroics and although many products are offered, quality and response times are poor and competitors have more up-to-date feature sets
  • teams launch “V1” of a product and then are re-assigned to focus on another product; engineers are given limited opportunity to develop architectural expertise before being reassigned elsewhere; sense of ownership suffers; architecture rots in place as only critical patching is permitted
  • teams avoid choosing service or product related names since there is the expectation of frequent product focus reassignment; or in the case of contracting, the business usually fails to win a contract renewal for subsequent work beyond initial efforts (or fails to direct the expertise developed in the contract into their own offerings)
  • career growth is narrowly defined to include skill acquisition only; there are no levels; hiring is limited to a narrow band of experience ranges; mentorship is not a priority since recruiting purposely attempts to hire engineers of similar ability
  • in addition to discouraging technical hierarchy, non-technical career growth is also narrowly defined to skill acquisition; leadership roles available to individual contributors are end with becoming a team lead and are not considered a promotion but a lateral
  • being a generalist is actively encouraged (makes it easier to assign you to something new for the next project) and developing deep architectural expertise is discouraged

This leads to key questions to ask when evaluating any engineering organization, whether you are a part of it, considering joining it, or contracting with it:

  • Against what standards can I expect the engineering organization to deliver? How can I judge the likelihood that the organization can deliver high quality, consistent work across all features and beyond V1?
  • What capacity is there in the organization to take on work? What evidence is there that underperforming products and technologies are regularly pruned to make room for new opportunities or to continue or increase investment in successful products? How much does this organization rely on heroics to make up for poor planning?
  • Who are the architects, the mentoring engineers? What are their visions for the organization and products and the technologies they work with? What evidence is there of allowing people to specialize, to learn and own something deeply long-term?
  • How are the teams named and organized? Are they aligned to products and services? Do they share processes and standards? Is a sense of product ownership actively encouraged? When a product is sunset, how are the engineers helped to find new homes in the organization? When a new project is undertaken, how is it staffed?
  • Are there career ladders — i.e. technical leadership and people management? Are there examples of people that have “risen the ranks” more than a single “rung.” To what extent is first line and middle leadership valued? Is it considered a promotion? Do they hire junior and staff engineers or is hiring limited to senior only? Are senior leadership positions routinely staffed from outside?

It’s the beginnings of a “sniff test” there. I expect I’ll be writing more on this. Comments?

Photo by Csaba Tomcsak from FreeImages

How to go from Developer to CTO

An (overly) ambitious title for the post notwithstanding, Simon Dowling offers a fair number of actionable insights on this quick read on the Venturi Group blog, including this:

As a CTO you are not there just to further your own agenda, not to just ‘look good’, but to drive the company forward as a whole. You are the single person others look to for decisions on short-term, tactical matters as well as plans for long-term, strategic goals.
 
Nobody is perfect. And trying to be perfect is not your job. Your job is to make informed decisions using the information at hand. Or in cases where there isn’t enough information, to set about collecting more so that a decision can be made….

….the easiest way to train this skill is to be forced to make these kinds of decisions in front of others.

Don’t let the dangerously innocuous pandas maul your career

A firm warning about career blind spots from the Harvard Business Review couched in an amusing metaphor.

Having assessed over 2,000 CEOs and over 18,000 C-suite leaders since 1995, we are struck by how often careers of talented executives stall or even derail because of seemingly trivial issues, many of which are utterly fixable. We call these types of issues “pandas.” Pandas look innocent, but their powerful jaws deliver a bite stronger than a jaguars’. Pandas can be painfully costly to individuals whose careers stall for reasons unbeknownst to them and to organizations and managers unable to develop talented leaders to their full potential.

Elena Lytkina Botelho and Katie Semmer Creagh

Always Be Clarifying What Success Looks Like

By the end of the project, we had done more than we probably needed to. Honestly, _far_ more than we needed to. The requirement had come down to build “Service X”, and the team rallied and pulled it off. But, in hindsight, I think we might have been able to deliver sooner – if I had put more effort into clarifying what success looked like for our stakeholders, and been more ruthless about stripping down the service to the bare essentials to meet that yardstick.

In a way, it is like that part of The Martian (a great book and a good movie) where the main character, marooned astronaut Mark Watney, has to strip everything he can from the sole surviving Mars Ascent Vehicle (MAV) in order to meet his rescuers high above the red planet. The weight of things like the hatch, chairs, dashboards, and nose cone of the MAV were so heavy that it limited the altitude the MAV could reach. Success (getting Mark off the red planet) was not going to be achieved with all that excess weight.

Engineering leads and managers face a similar situation frequently. Projects assigned to their teams are often not accompanied by a lot of clarity around what success looks like. A lot of assumptions end up being made unnecessarily. The success yardstick might be assumed to be a fully functioning, pressurized, climate controlled MAV with comfortable seating and spare spacesuits, when the actual success yardstick might simply be a means of getting a marooned astronaut into high orbit.

It comes down to engineering leads and managers to always be clarifying – to always be asking their stakeholders “Why?” – and to always be jettisoning (or at least postponing) unneeded weight – the earlier in the project the better.

We should always be asking:

  • Why do we want to launch product or service X? And then ask why again. Unpack the why’s a few times. “Because the CEO said so” isn’t good enough. They have a “Why” too.
  • What does success look like? What sorts of customers do we want to attract?
  • What are we assuming about our customers’ mindsets? Where are we trying to read their minds without actually asking them what matters to them? Hint: your ability to read your customers’ minds is far, far weaker than you realize.
  • What stakeholder requirements are based on their own assumptions (or worse, mind-reading) versus stakeholder requirements that are backed by validated insights? Drive stakeholders to back up their requirements with facts and data.
  • What is the bare minimum our customers need? Do we really need to be able to provide multiple levels of service? Is there one level that we can start with first? OK, now ask again – within that level of service is there even more we can jettison? Repeat this often.
  • How much time do we have? Why did you pick that deadline? What are the other events you’re trying to tie this product or service’s launch with
  • How much money does this need to make in the first year? The second? What support costs are acceptable? Does everything we are doing support that? Why or why not? What can we jettison to reduce support costs?
  • What customer acquisition cost is too high? What minimum long term value is expected? How soon must that value be realized? This can also help engineering get a sense of which features/services need to be streamlined and prioritized or written at all.
  • How much flexibility or scalability does the system really need to support right now? Where are the requirements unclear, and where can we somewhat safely assume things are less likely to change? Over-engineering flexibility is expensive and slows velocity.
  • How many new customers does this need to generate for us? What rate of churn is too high?
  • What key metrics are needed to know if everything is meeting expectations?

Essentially, always be clarifying what success looks like. What the yardstick is.

What questions would you add to your repertoire when it comes to clarifying success with stakeholders and jettisoning unneeded scope? Where might you have excess weight on your project that is keeping you from the best velocity towards that first (or next) release? Where have you, your team or your stakeholders assumed complexity where it is unwarranted and doesn’t meet anyone’s actual yardsticks? What unessential effort is going to make the project possibly miss some critical rendezvous?

Props to Jeff for the constructive feedback that sparked this post.

Photo credit USGS

Thoughts on “The Manager’s Path” by Camille Fournier

It’s a quick read, focusing on some of the unique challenges of leadership at technology companies, and the progressive structure (e.g. team lead to manager to manager of managers) makes it easy to jump in at whether level you find yourself at on the ladder (and to see what you missed and should have picked up on a lower rung… or what to expect on the next rungs.).

Here are a few things that especially resonated with me as I reflected on past lead and manager roles I’ve been in.

Creating a 30/60/90-day plan

“Another approach that many experienced managers use is to help their reports create a 30/60/90-day plan. This can include basic goals, like getting up to speed on the code, committing a bug fix, or performing a release, and is especially valuable for new hires and people transferring from other areas of the company. The more senior the hire, the more he should participate in creating this plan. You want him to have some clear goals that will show whether he’s learning the right things as he gets up to speed. These goals will also require some work from you and the team, because it’s very rare that everything is self-evident, well-documented, and total obvious to a newcomer. (pg. 51)”

This was one of my big takeaways from the book. First, that the amount of work the manager does for the 30/60/90-day plan is inversely promotional to the seniority of the hire. Second, the need for the manager to have clear goals and expectations into the next quarter – so that the things the new hire are working on are well-aligned with the team goals. Third, that team knowledge should be documented and continually refreshed (a worthy component of the 30/60/90-day plan itself.)

Fournier continues:

“Unfortunately, sometimes you will mis-hire a person. Having a clear set of expected goals for your new hires that you believe is achievable in the first 90 days will help you catch mis-hires quickly, and make it clear to you and to them that you need to correct the situation. (pg. 51)”

I’ve had mis-hires and, in hindsight, having this 30/60/90-day plan in place would have saved both me as the manager and them as the new hire a lot of grief and brought clarity sooner in the employment relationship. In some ways, the performance improvement plans that managers must pull together in the closing acts of a mis-hire are a too-late echo of some of what a 30/60/90-day plan could contain.

The Shield

“You may be a shield, but you are not a parent. Sometimes, in combining the roles of shield and mentor we end up in a parenting-style relationship with the team, and treat them like fragile children to be protected, nurtured, and chided as appropriate. You are not their parent. Your team is made up of adults who need to be treated with appropriate respect. This respect is important for your sanity as well as theirs.” (pg. 84)

Fournier cautions managers to NOT attempt to insulate the team from the drama originating from elsewhere in the company, but to address it openly and candidly with them – like adults, and without adding to the drama yourself.

To me this means that when your team’s performance is criticized, perhaps undeservedly, by senior leadership — that a great manager discusses the criticism candidly and dispassionately with the team AND with their own manager, who quite possibly has some unfinished communicating to do with their own manager.

Flex Your Own Product Muscles

“Strong leadership cares about cultivating success and having a team that delivers successful projects, which means honing your understanding of what is important to your customer…. Taking time to develop customer empathy is important because you’ll need to give your engineers context for their work.” (pg. 85)

This is so important, it should be in bold and memorized by all managers. It is not at all good enough to design and implement. It is critical to validate the design and the resulting product through the customer’s eyes, and to the extent the manager and team members (but especially the manager) can adopt their customer’s view of their needs, their workflows, their blind spots — the better. This is table stakes for durable products and even businesses in this hyper competitive age.

Strategies for Handling Roadmap Uncertainty

“A very common problem that manager at all levels face is the challenge of changing product and business roadmaps. Especially in smaller companies, it’s hard to get people to commit a year in advance to the work that will be done for the next year…. This is really hard for engineering managers to deal with. Changes in strategy are where being stuck in “middle management” feels the most unpleasant. (pg. 151)”

Fournier gives a few powerful suggestions for dealing with poor or incomplete roadmaps. The first one really resonated with me.

“Be realistic about the likelihood of changing plans given the size and stage of the company you work for. If your startup has a history of changing the year’s plans every summer to account for the business results from the first half of the year, be prepared for a change in the summer and try not to promise things to your team that would require continuity beyond that point. (pg. 151)”

She continues…

“Projects change. Teams may even be disbanded or moved around in ways that you don’t understand or agree with. As a manager, the best thing you can do to help people feel capable of typing up loose ends, stabilizing the current in-flight projects, and easing into their new work in a controlled fashion. This is an area where you can and should push back. Make sure that your teams get adequate time to finish up current work. (pg. 153)”

At my current company, projects frequently get mothballed or back-burnered within a year or so after they begin — priorities change very rapidly. Pushing back for time to park the projects properly and prepare the team for their new work is an area I will be doubling down on in the future.

Fournier concludes:

“The calmer you can be in the face of these changes, and the better you can show (or fake) enthusiasm for the new direction, the easier the transition will be for your whole team. When you are faced with waves, you can let them pull you under or you can learn how to surf. Hang 10. (pg. 153)”

Learn how to surf. Expect the waves to come (they will). Those a good things to remember.

Again, overall a quick accessible read, and one of those texts that you can dog ear and refer back to frequently (and not just as you make career transitions). Highly recommended.