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.
The deadline for submitting comments on the National Telecommunications and Information Administration’s (NTIA) proposed approach for federal privacy law was extended recently to November 9, 2018.
Here’s what I submitted to the NTIA this morning. It’s not too late for you to do the same.
Re: Docket 180821780-8780-01
Federal Register Vol. 83, No. 187, p. 48600 – 48603
Developing the Administration’s Approach to Consumer Privacy
To Whom It May Concern:
Thank you for providing the opportunity to comment on the Administration’s proposed approach to consumer privacy. I have a few concerns I wish to raise.
1. Concerning Section I.B(4) – the Self-Regulatory Approach Proposed
It is not completely clear whether the approach detailed in the RFC would lead to federal law governing the collection, storage, use and sharing of consumer information, or merely to voluntary guidelines. Since the RFC cited both the NIST “voluntary risk-based Privacy Framework” as well as the self-regulatory Fair Information Practice Principles (FIPP), one could conclude that the NTIA is proposing a voluntary approach. This is important and should be clarified.
Assuming a voluntary approach is being proposed, the Administration should re-review the findings of the FTC “Privacy Online” report to Congress in June of 1998. The FTC concluded, with respect to FIPP, that:
To date, industry has had only limited success in implementing fair information practices and adopting self-regulatory regimes with respect to the online collection, use, and dissemination of personal information.
It is out of the limited success of these self-regulatory regimes that laws like the Children’s Online Privacy Protection Act of 1998 came to be and, more recently, that individual states have enacted non-voluntary regulations like the California Consumer Privacy Act of 2018.
It is noteworthy that although FIPP recommends that consumers should be given notice of information practices before any personal information is collected from them, that it wasn’t until the enactment of the EU’s General Data Protection Regulation in 2018 that such notices were added to the online sites of many U.S. based businesses.
2. Concerning Section I.B(1) – Regulatory Harmonization
This section seems to suggest that the Administration will be seeking to preempt the privacy regulations enacted independently in states like California and Vermont with voluntary principles. This is important and should be clarified.
Although the RFC makes a valid point about the added burden incurred by businesses to respect the various regulations in each of the states in which they do business, preempting state regulations with federal voluntary principles will undermine the trust that is just beginning to be re-built between consumers and businesses in states with new privacy regulations on the books.
If the Administration is to craft preemptive law, it would be better for it to be a non-voluntary regulatory framework that leverages some or all of the requirements of California Consumer Privacy Act of 2018 and the Vermont Data Broker Law of 2018.
Further, similarly, it is not clear whether the “Risk Management” outcome (Section I.A(6)) is intended to preempt states’ data breach disclosure laws. If so, then a non-voluntary regulatory framework (with the state laws informing a minimum) is far more likely to be effective at increasing consumer trust than stripping states’ breach notification protections.
3. Response to Section II.G – “Are there… any outcomes or high-level goals in this document that would be detrimental to achieving the goal of achieving U.S. leadership?”
Although the outcomes enumerated in section I.B of the RFC (e.g. transparency, control, minimization, security, access and correction, etc.) laudably mirror recently enacted privacy regulation abroad and within, I believe relying on voluntary principles being adopted by industry and preempting state law would, instead, directly undermine the goal of achieving U.S. leadership in online privacy.
Thank you for taking these concerns into consideration.
WordPress Core Contributor for Privacy
26 years professional experience in engineering, software development and management
Alumni, Virginia Polytechnic Institute and State University, BSEE
I wrote this plugin a few months back, use it on all my sites, and finally got around to uploading it to the WordPress.org plugins repository this morning.
The plugin increases your users’ privacy by hiding Profile Pictures (Gravatars) from logged out users (and bots) visiting your site.
It also allows individual registered users on the site to choose whether or not they have a Gravatar displayed for them in their User Profile settings.
Why is this important? Primarily because the “hash” that Gravatar uses to retrieve and display your picture can be used to find other places on the web where you have provided comments or posts and could even be used to reveal your email address in some cases – here’s a good in-depth article by Wordfence on the risks.
But it will also significantly change the ground rules for users of products that have grown enormously popular, generating a following among fiercely independent purchasers who want to fly with limited or no restrictions.
Replace “purchasers” with website owners and “fly” with “have a web presence” and you’ll get my drift.
This is a unique opportunity for privacy professionals to weigh in on the policies and laws that affect many of us and our work, not just in the United States of America, but worldwide.
Tick, tock! Comments are open until October 26, 2018.
A complete copy of the proposal is available from the Federal Register at https://www.ntia.doc.gov/files/ntia/publications/fr-rfc-consumer-privacy-09262018.pdf and more information is available on the NTIA website at https://www.ntia.doc.gov/federal-register-notice/2018/request-comments-developing-administration-s-approach-consumer-privacy
MIT has a great article on commenting on pending legislation here: http://mitcommlab.mit.edu/broad/commkit/public-comment-on-pending-legislation/
I’ll post my comments here in a follow on post once I assemble them.
I deleted my Facebook account a few months ago. Last week I deleted my Twitter account. This article perfectly sums up why: https://www.wired.com/story/im-deleting-all-my-old-tweets/
“Ten Arguments for Deleting Your Social Media Accounts Right Now” by Jaron Lanier.
Already deleted Facebook earlier this year. Let’s see if I keep Twitter. Book review to follow.
I recently had the pleasure of attending the 1st Annual Innovation and Technology Law Symposium held by Seattle University’s School of Law. It was an one day series of moderated panels on Innovation and Regulation in Blockchain and Financial Tech (FinTech). Panelists included faculty from the school as well as experts from Microsoft, from Washington State Department of Financial Institutions, and a few startups too.
Although all the discussion was for the most part captivating, the most intriguing part of the conference though was the final panel on regulatory sandboxes. This ended up having direct parallels to the privacy regulations I’m most interested in and working on each day — especially when Youssef Sneifer of Microsoft Payments remarked that it was no small feat to acclimate the software developers in his part of Microsoft to the realities of working in a regulated environment – something that most software developers don’t have experience with. And he’s not alone in this remark!
Although I’ve worked in regulated industry most of my career, first CE/UL/FCC for satellite communications hardware and then later laws like HIPAA while developing software for medical devices, his point really struck me – because most of the web and app developers tackling the changes needed for privacy laws like the GDPR have little to no experience working in a regulated environment – they are more likely to be told to “move fast and break things” and that’s just not the way things work when working with radio or healthcare – and now it is no longer the way when working with people’s personal data.
So I asked, how does one help create a culture of compliance where there formerly was little or no regulation or enforcement, like in the case of privacy? Youssef replied that it had to start at the top, that the leadership had to set the tone that compliance was a top priority, was non-negotiable and that developers and managers were responsible to understand the requirements of the law and make it happen. Lucinda Fazio, the sole regulator on the panel, added that, when a regulator sees that regulatory compliance is being reinforced in the company, the regulator reacts differently if/when that company makes a misstep. Aaron Gregory of Remitly added that ultimately it becomes about trust and ideally becomes part of your brand – becomes a fundamental for your employees.
Later, another attendee mentioned that he agreed with Youssef but that you especially needed to get the sales team on-board too for compliance culture to catch. Shortly after that a third attendee stopped me in the hallway and mentioned the importance of finding the distinct “whys” (they’ll be different) for different groups or individuals throughout the organization – why regulatory compliance should matter to them, whether financial law or privacy law or what have you.
I think they were all right – you need a strong privacy mandate from the top down AND you need sales and marketing to see regulatory compliance as something marketable and not just an encumbrance AND you need to find the whys for the software developers and other roles in your company to begin make compliance – financial, privacy, or what have you – part of a company’s culture. And that’s the challenge for all of us working on the web and on apps now – in a post GDPR world – helping to get those cultures started and flourishing in our companies.