Ultimately, being nice as a leader is selfish. It doesn’t serve the team. It serves your ego. The team is looking to you to help them achieve a goal. And instead, you’re looking to have your decisions, actions, and yourself perceived as positive by them.Claire Lew
A great article from Entrepreneur on the downsides of having employees overly reliant on leaders for decision making.
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.
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.)
“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.
“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)”
“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.
“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.