On joining the product team

Almost two years ago I published a blog post and video on Being a Program Manager at Microsoft, in which I shared some of my personal experience and advice based on my decade plus at Microsoft. I’ve received an incredible amount of feedback[1] on that 2020 post… and now it’s time for a follow-up.

My last few posts have focused on topics related to problem domains and solution domains, including how these concepts relate to Power BI and my work on the Power BI CAT team. What about for people who are currently Power BI or data professionals who might be thinking about changing careers to join the product team? These are pretty abstract concepts – what do they mean to you?

This conversation calls for an analogy, and since I don’t know anything about driving race cars or automotive mechanics, I’m going to use an analogy about race car driving and mechanics[2].

As a Power BI or data professional, you’re like a race car driver.

Your job is to win races. You need to respond to the rapidly-changing demands of the moment to deliver victory for your team[3]. You’re in the spotlight,

As a race car driver, there are two main factors that contribute to your wins and losses:

  1. Your skills as a driver
  2. The performance of the car you’re driving

To win a race, you need to know how to get the most from your car, and make it perform for the conditions on the track, and within the rules of the race.

As a program manager on the product team, you’re like a mechanical engineer responsible for designing, refining and tuning the race car engine.

Your job is to deliver an engine that performs the way your drivers need it to perform, as part of the larger system of the race car as a whole. The race car needs to have the capabilities and characteristics that enable drivers to win races, and the engine is a key part of that… as is the steering, suspension, and whatever other subsystems make up a race car.

Your job is not to drive the race car, and you can excel at your job without ever having won (or driven in) a race.

Re-read that last sentence and pause to let it sink in. If you’re thinking about joining the product team that makes your favorite software tool or platform, you’re also thinking about giving up the day to day job of using that software.

Even more than this, the skills that you’ve built as a race car driver – or as a data professional – are no longer directly relevant. Please don’t get me wrong – if you’ve spent years implementing data and BI solutions this will serve you very well as a program manager on a product team building data and BI tools. But that experience will be valuable in the way that having been a race car driver could be valuable in informing the design and optimization of race car engines.

Having an intimate understanding of – and deep personal experience with – the problem domain can help inform your work in building and improving the solution domain… but your job is no longer what it used to be. You need to learn and master new skills to be successful in the new role, and that means no longer being the expert on the problem domain like you used to be.[4]

This can be a difficult realization and wake-up call for people making a career change, because it means giving up – or at least moving away from – the work they know and love. It can also mean discovering new work and new challenges that they may love even more… but change is hard at the best of times, and it doesn’t always come at the best of times.

I hope this blog post and analogy[5] doesn’t scare anyone off. Working on a product team can be incredibly fun and rewarding – it’s just different from working with the product that the team builds and ships. It’s another situation where the problem domain and solution domain differ in ways that aren’t always obvious until you’ve had a chance to work in both worlds.

Joining the product team after working as a data professional changes your relationship with the product. What used to be your solution domain, where you were the expert responsible for understanding the product and delivering solutions based on its capabilities, now becomes your problem domain. You’re responsible for increasing its capabilities to make it more useful for others to build their solutions, but you’re no longer building those solutions yourself.

 


[1] I continue to believe that this video may have been the best thing I did in 2020. I’ve had dozens of conversations with people around the world who want to be program managers or product manager – at Microsoft or other tech companies, and some of them have already achieved their goal. This feels like I’m actually making a difference in the world when the world is doing its best to make me feel powerless, and that’s like a gift that keeps on giving. I may not be the only one who feels this way. While this post was in draft form waiting to be published, my friend Davide created a website to showcase this video – he even transcribed it! You can check it out here: http://aka.ms/being-a-ms-pm.

[2] Because of course I am. This is an analogy that presented itself to me in one of those conversations mentioned just one footnote earlier, and which works as well as any I’ve found so far.

[3] There are teams in racing, right?

[4] This is where it’s useful to have a person or team responsible for bridging these two worlds.

[5] Another possibly less scary analogy could have involved someone who loves eating becoming a chef in a professional kitchen. Since I know enough about these worlds to be dangerous, I didn’t trust myself to use this analogy without ratholing on lots of details no one but me would care about. Maybe I’ll try that one again when I have more time to think about it…

Thoughts on community

This post is mainly a story about how community has affected my career, and how it might affect yours as well. The post has been sitting in my drafts for a few months waiting for inspiration to strike. That inspiration came in this recent[0] data culture video where I talked about communities of practice inside enterprise organizations, and the ways that positive behaviors can be promoted and encouraged for these internal communities of practice – because the same patterns often apply to public communities as well.

So let’s talk about community.

No, not that Community. Technical community. Community like this:

hand-1917895_640

I started off my tech career as a Microsoft Certified Trainer (MCT) in 1996. I spent much of the next decade as a trainer, mentor, and consultant, but even though I was learning and growing year after year, the pace of that growth felt slow. I quickly became a medium-size fish in a tiny pond[1] and that was pretty much that. My career growth was limited in part by the company I chose to keep.

To be fair, there was an online[3] MCT community where I would often lurk and occasionally post, but I never took real advantage of it. I didn’t feel confident enough to post often, and for some reason traveling to a conference or other in-person MCT event just didn’t feel like something that was available to me – this was something that other people did, not something I could do.[4]

In late 2004 I started thinking about getting back to more training after a few years focusing on software development and consulting. I decided that the upcoming SQL Server 2005 release would be a great opportunity for making this change. Microsoft had made available to MCTs the preview versions of two “What’s new in SQL Server 2005” courses – one for developers and one for admins – and I was going to get certified to teach these courses as soon as they were available to offer. I’d been working with SQL Server since version 6.5, and much of my consulting work included developing solutions on SQL Server 2000, so this was a logical direction that matched my experience, skills, and interest.

To make a long story slightly less long – and because I’ve shared some of the details while this post was sitting in my drafts – that focus on SQL Server 2005 was my jumping off point to become an active member of the MCT and SQL Server communities. I was still doing many of the same things I’d been doing all along, but now I was doing them where more people could benefit, and where more people could see me doing what I did. And people noticed.

People noticed that I knew what I was talking about on technical topics, but mainly people noticed that I engaged in a constructive and helpful manner. That I gave more than I took.[5]

And this brings us to the concept of visibility from that earlier blog post, and the opportunity that comes from being seen kicking ass – being seen doing the great work you do every day. For me, being actively engaged in the MCT community led to my first job at Microsoft. People who knew me because of my community involvement let me know that there was a job I should apply for, and they put a referral into the internal HR systems to make it more likely I would get called for an interview[6], and the rest is history.

For you, being actively engaged in your community – whether it’s the Power BI community or something else – will likely mean something very similar. The details will be different because the context is different, but adding your voice to the communities you frequent is how you let the community know who you are and what you do.

When you answer questions – and when you ask them too – other members of the community will begin to understand what you do, and how you work. When you write a blog post or record a video, more people will begin to understand how you think, and how you communicate. They’ll learn from you, and they’ll learn about you.

This is good.

As more people learn about who you are and what you do, and as more people begin to see and value your contributions, they’ll start thinking about how awesome it would be if you could contribute more directly to their projects and products. For me this meant being asked more frequently to teach SQL Server and SSIS classes, and an increased volume of inquiries about consulting availability.[7] I had more opportunities for more interesting and better paying work because of my engagement with the community, and it changed my life for the better in many ways.

For you it will look different because the context is different, but you can follow the same pattern. Your contributions to the community organically become your resume[8], your marketing web site, your demo reel. Potential employers and potential clients[9] will have a more complete picture of how you work than a job interview can provide, and that can make all the difference.

Implied in this pattern is the positive nature of your community contributions. If you’re a bully or a gatekeeper or engage in other types of abusive behavior… people notice that too. This can become its own opportunity for improvement, because if you’re more mindful about presenting the side of you that you want people to see, the more likely you are to become that better version of yourself.[10]

Engaging with the community changed my life. It can change yours too.


Interesting side note on timing: I joined Twitter ten years ago this month.

At that time I had just accepted a position on the SQL Server Integration Services  (SSIS) product team, and had asked one of my new colleagues where the SSIS community was centered, and he pointed me there. The rest sort of took care of itself…


[0] Referring to this data culture video as “recent” gives you some insight into how long this post languished in draft form after the introduction was written.

[1] This is kind of like saying “big fish in a small pond” but self-aware enough to realize I’ve never been a large fish on any scale.[2]

[2] I am so sorry, and yet not sorry at all.

[3] Two words: Usenet newsgroups.

[4] I’ve thought about this a lot in the intervening years, and believe that the root cause was probably a combination of my rural, poor, opportunity-sparse upbringing, and my mental health challenges, but I doubt I’ll ever know for sure.

[5] I’m generalizing here, and making some big assumptions based on the available evidence. This is what I think people noticed based on the way that they reacted, but only a handful said so. Of course, they typically said so when offering me work…

[6] This is something I have done a few times over the years myself, and there’s no better feeling than knowing I played some small part in helping Microsoft attract new talent, and in helping a member of the community achieve their career goals.

[7] For me it also meant that I roughly doubled my billing rate over the course of 18 months. I had so many inquiries that I was turning down almost all of them because I didn’t have the bandwidth to say yes, and decided to take advantage of the laws of supply and demand.

[8] This 2016-era post from MVP Brent Ozar presents a much more prescriptive approach to this theme.

[9] And potential employees as well, in the fullness of time.

[10] And let’s be honest – if you’re an insufferable asshole who refuses to change, participating in a community is a great way to let people know, so they can know that you’re someone they should avoid hiring, interviewing, or contracting. This is also good.

Never underestimate the voice of the customer

Most of what I do in my day job involves listening.

A sculpture of men with ears pressed to a brick wall - Image by Couleur from Pixabay
It’s better to put your ear up to the wall than it is to bang your head against it.

Specifically, I spend a lot of time listening to people who use Power BI[1] talk about why they use it, how they use it, and where they struggle along the way. I ask a few questions to get them started, and then I ask a few follow-up questions to help them along as they tell their story – but mainly I listen.

I listen, and then I use what I hear to help make Power BI a better tool for these people and their organizations’ needs.

I listen for patterns and trends, and for a signal to emerge from the noise of hundreds of conversations. When it does, I make sure that the right decision-makers and leaders hear it and understand it, so they can take it into account as they decide where to invest and how to prioritize those investments.[2]

I listen with an informed ear. I spent almost 15 years building software and data solutions, so I understand a lot of the technical and organizational challenges these people face. I spent the next decade or so building data products and services as a program manager at Microsoft, so I understand a lot of the challenges involved in prioritizing and building product features. And perhaps most importantly, I am genuinely interested in listening to and learning from the people with whom I talk. I truly want to hear their stories.

Of course there’s only one of me, and I can’t spend my whole workday listening to people tell their stories… so I’ve helped build a team to listen[3], and it’s making a difference. The next time you see an announcement about new capabilities in Power BI that will improve the lives of large enterprise customers, odds are this team had a hand in making those capabilities a reality.

Why am I telling you all this? This is my personal blog, and I’m not looking for a job, so who cares, right?

You care.

You care because this type of listening is a thing that you can do to make better software. You can do this whether you’re building commercial software or if you’re part of a BI team that needs to build solutions for larger user populations.[4]

You care because letting the people who use your software – or the people you want to use your software – talk about what what’s important to them… will let you know what’s important to them. And if you’re really listening, you can use what you learn to make better decisions and deliver better products and features.

If you’re genuinely interested in the people who use the software you build, you should consider giving this approach a try.


[1] These people tend to be the business and IT owners of Power BI in large enterprise organizations, but they can be just about anyone involved in implementing, adopting, using, or supporting Power BI.

[2] If you’re interested in learning more about the Power BI product team’s planning process, I cannot recommend highly enough this 2019 presentation from Will Thompson.

[3] As part of building that team we all read and/or re-read Lean Customer Development by Cindy Alvarez. If you have not yet read this awesome book, there’s no time like the present.

[4] I honestly don’t know if this type of rigor is appropriate at a smaller scale, because I haven’t done it and haven’t personally seen it done. I suspect that it would be very valuable, but also suspect that there may be lighter-weight options that would provide a better return on investment.

Webcast: Unleashing Your Personal Superpower

Last week I delivered a presentation for the Data Platform Women In Tech‘s Mental Health and Wellness Day event.

The recording for my “Unleashing Your Personal Superpower” session is now online:

I hope you’ll watch the recording[1], but here’s a summary just in case:

  • Growth often results from challenge
  • Mental health issues like anxiety and depression present real challenges that can produce “superpowers” – skills that most people don’t have, and which can grow from the day-to-day experience of living with constant challenge
  • Recognizing and using these “superpowers” isn’t always easy – you need to be honest with yourself and the people around you, which in turn depends on being in a place of trust and safety to do so

In the presentation I mainly use an X-Men metaphor, and suggest that my personal superpowers are:

  1. Fear: Most social interactions[2] are deeply stressful for me, so to compensate I over-prepare and take effective notes for things I need to remember or actions I need to take
  2. Confusion: I don’t really understand how other people’s brains work, or the relationship between my actions and their reactions – to compensate I have developed techniques for effective written and verbal communication to eliminate ambiguity and drive clarity
  3. Chaos: My mind is made of chaos[3], which causes all sorts of challenges – to compensate I have developed a “process reflex” to understand complex problems and implement processes to address or mitigate them

I wrap up the session with a quick mention of the little-known years before Superman joined the Justice League, which he spent as a Kryptonite delivery guy, and absolutely hated his life. Once he found a team where he could use his strengths and not need to always fight to overcome his weaknesses, he was much happier and effective.

In related news, if I could only get these Swedes to return my calls, I’m thinking of forming a new superhero team…


[1] And the rest of the session recordings, because it was a great event.

[2] Think “work meetings” for starters and “work social events” for an absolute horror show.

[3] I have a draft blog post from two years ago that tries to express this, but I doubt I will ever actually finish and publish it…

Upcoming webcast: Unleashing your personal superpower

This damned pandemic[1] has been getting the best of me, but Talking About Mental Health is Important, and it’s more important now than ever. So when I learned that the Data Platform Women in Tech user group was hosting a free day-long online event focused on mental health and wellness, I knew I wanted to participate.

Today I am excited to announce that I will be presenting on “Unleashing your personal superpower” on Friday May 7th:

Building a successful career in tech is hard. Every day is a battle, and sometimes the barriers placed in your way seem insurmountable. Wouldn’t it all be easier if you had a superpower?

Maybe you do.

Greta Thunberg famously described her Asperger’s syndrome diagnosis as being a superpower: “I’m sometimes a bit different from the norm. And – given the right circumstances- being different is a superpower.” We can all learn something from Greta.

In this informal session, Microsoft program manager Matthew Roche will share his personal story – including the hard, painful parts he doesn’t usually talk about. Matthew will share his struggles with mental health, how he found his own superpower, how he tries to use it to make the world a better place… and how you might be able to do the same.

Please join the session, and join the conversation, because talking about mental health is important, and because the first step to finding your superpower is knowing where to look.

You can learn more about the event here, and you can sign up here.

I hope you’ll join me!


[1] Of course it’s more than just the damned pandemic, but when I first typed “this year” I realized this year has been going on for decades now, and I figured I would just roll with it because finding the perfect phrase wasn’t really important to the webcast announcement and anyway I expect things will probably suck indefinitely and isn’t this what run-on sentences in footnotes are for, anyway?

Deep thoughts on dataflows

As you may have noticed, life is complicated and keeps getting in the way of my plans to be a more active blogger and YouTuber[1]. I haven’t released a new dataflows video of my own in far too long[2], but my teammate Kasper is helping out by doing the hard work for me:

Last week I had an awesome conversation on “everything dataflows” with Kasper and the video is now available on his excellent Kasper On BI YouTube channel. In this hour-long video we talk about a lot of the “big picture” topics related to dataflows, including how dataflows fit into a larger data estate – and when you should use them, or avoid using them.

Please check it out, and let me know what you think!


[1] If this isn’t the name of a social media platform for potatoes, it should be.

[2] To add insult to the injury that is life in a global pandemic, my video editing PC died a few weeks ago. I now have it back up and running, but I lost all of my project templates and works in progress, which is likely to introduce more delays. FFS.

Being a PM at Microsoft – Part 2

Last year I published a blog post and video on Being a Program Manager at Microsoft, in which I shared some of my personal experience and advice based on my decade plus at Microsoft. I’ve received an incredible amount of feedback[1] on that 2020 post…

…and now it has an unexpected follow-up:

My teammate Kasper de Jonge has started a YouTube channel, and in addition to some great technical deep dive content, he has a series of interviews with members of the Power BI product team and the broader data platform community.

This week he’s published an interview with Power BI Group Program Manager Kim Manis, where they spend 45 minutes talking about being a PM in the Power BI team… and it’s fascinating.

In the interview Kim provides an insider’s perspective on topics ranging from how we decide what features to build, how we build and ship them, to what are you looking for in a PM candidate when you’re hiring.

I’ve been a PM at Microsoft for well over a decade, and have worked on Power BI for almost three years now… and I learned a lot from their conversation. If you’re reading this post I am very confident you’ll learn something too, and will enjoy the whole delightful conversation.


[1] I’ve come to believe that this video may have been the best thing I did in 2020. I’ve had dozens of conversations with people around the world who want to be program managers, which feels like a chance to make a difference in the world when the world is doing its best to make me feel powerless.

Old videos, timeless advice

It’s 2021, which means my tech career turns 25[1] this year.

It me

Back in 1995 an awesome book was published: Dynamics of Software Development by Jim McCarthy. Jim was a director on the Visual C++ team at Microsoft back when that was a big deal[2]. The book is one of the first and best books I read as a manager of software development teams, and it has stood the test of time – I still have it on the bookshelf in my office[3].

Of course, I wasn’t managing a software development team in 1995. I discovered Jim’s wisdom in 1996 or 1997 when I was preparing to teach courses on the Microsoft Solutions Framework[4]. When I opened the box that the trainer kit came in, there was a CD-ROM with videos[5] of Jim McCarthy presenting to an internal Microsoft audience on his “rules of thumb” for reliably shipping great software. When I first watched them, it was eye-opening… almost life-changing. Although I did have a mentor at the time, I did not have a mentor like Jim.

The second time I watched the videos, it was with my whole team. Jim’s rules from these videos and his book became part of the team culture[6], and I’ve referred back to them many times over the decades.

Now you can too – the videos are available on YouTube:

Some of the rules may feel a bit dated if you’re currently shipping commercial software or cloud services[7] but even the dated ones are based on fundamental and timeless truths of humans and teams of humans.

I’m going to take some time this week to re-watch these videos, and to start off the new year with this voice from years gone by. If you build software and work with humans, maybe you should too.


[1] Damn, that is weird to type, since I’m sure I can’t even be 25 years old yet.

[2] It may also be a big deal today, but to me at least it doesn’t feel quite as much.

[3] Not that I’ve seen my office or my bookshelf in forever, so this assertion should be taken with a grain of 2020.

[4] Fun fact: if you remember MSF, you’re probably old too.

[5] Because in those days “video” and “internet” weren’t things that went together. This may or may not have been because the bits had to walk uphill both ways in the snow.

[6] To the extent the team could be said to have a shared culture. We were all very young, and very inexperienced, and were figuring things out as we went along.

[7] Back in 1995 CI/CD wasn’t part of the industry vocabulary, and I can count on zero hands the clients I worked with before joining Microsoft who had anything resembling a daily build.

Representation and visibility

tl;dr: We need more representation in tech, in part because career opportunities come from kicking ass where people can see you, and that comes from knowing that you belong, and that knowing comes from seeing people like you already belonging.

Image by Gerd Altmann from Pixabay

Representation is a complex topic. Being a straight, white, cisgender, American man, I don’t have a lot of personal experiences with the lack of representation. But I do have one, and it involves swords.

Back in 2004 a friend of mine sent me a copy of the first edition of The Swordsman’s Companion by Guy Windsor. At this  point I had no idea that people were recreating medieval martial arts and fighting with steel weapons[1], so I read through the book and eventually sold it at a yard sale. I was interesting, and I loved the idea of being able to do what the people in the book were doing, but deep inside I knew that people like me didn’t actually do things like that. I was wrong, of course, but at the time the totality of my life experience told me I was right, and I simply didn’t question this knowledge.[2] Ten years passed before this opportunity presented itself again – ten years in which I could have been studying, practicing, competing, improving.

Now take this almost-trivial example and apply it to your career. What if you had never seen someone like yourself in a job role? How would you know that this was something that you could do, that this was a path that was open for you to travel?

When I look back on my career in IT, I can see tipping points – places where everything changed, and my life was forever improved. All but one of them (we’ll come back to this one) happened because someone saw me kicking ass and said “I want you to come kick ass with me.”

  • In 1996 when Dave saw me excelling as an applications trainer and offered me the opportunity to become a technical trainer and MCT.
  • In 1997 when Jeff saw me teaching Windows NT networking and offered me a job with a much higher salary and responsibilities that included consulting and application development.
  • In 2003 when Carolyn offered me a full-time contract as I was leaving my then-collapsing employer and starting my own consultancy, and when I simply didn’t know how I would pay my mortgage in six months, or pay the hospital bills for my impending second child.
  • In 2005 when Corey saw me teaching a beta SQL Server 2005 course, and said “you need to come work at TechEd this year.”
  • In 2007 when I quoted Ted almost double my then-standard daily rate to get him to quit nagging me about working for him, and he instantly agreed and asked how soon I could start.
  • In 2008 when Ken and Dave told Shakil that I was the only person who could do the job he needed done, and he ended up offering me my first job at Microsoft.
  • In 2011 when Matt learned I was looking for a new role and said “we have an open PM position on the SSIS team – let me introduce you to the hiring manager so you can see if you want to apply.”
  • In 2017 when Kasper kept subtly mentioning how much he loved the team he was on, until I finally figured out he wanted me to join it.

This is my story, and I’m including names both to say “thank you” and to make it real – these are the people who enabled me to be who I am today, where I am today, doing what I love so much today. I’ve heard variations on this story from many of my colleagues and peers, but this one is mine.

Please don’t get me wrong – I don’t believe anyone was giving me any handouts. At every step along the way I was doing the work – I was working hard, pushing, trying, struggling to kick as much ass as I possibly could. I was really good, because I had studied and practiced and put in the long hours to learn and improve – but without these people seeing and recognizing my hard work, the opportunities simply would not have existed for me. At any of these tipping points, if I hadn’t been where these people could see me, the moment would have passed, and the opportunity would have been lost. Each opportunity was dependent on the opportunities that came before it – each one depended on my being where I was, being visible and being seen.

This brings me back to that very first tipping point. In 1996 I saw a classified ad[3] for a job teaching people how to use Microsoft Windows and Office, and I applied for it.

And this brings us back to representation.

I applied for that first job because I could see myself in the role – I knew that I could do it. I had no difficulty picturing my 20-something Christian white male self in that role, and neither did the folks doing the hiring.[4]

But what if I was female, or Black, or transgender? What if I looked at an industry that was overwhelmingly male and overwhelmingly white and overwhelmingly cis, and knew that I didn’t belong, because there was no one like me doing things like that? Would I have opened that very first door, on which every later door depended?

I can’t answer that, but looking at the still-white and still-male faces around me every day in tech, I have every reason to believe that many candidates would see this lack of representation and infer from it a lack of opportunity – and never take that first step. And for those who do take the first steps I only need to look around to see the barriers that the tech industry put in place for women and minorities, letting them know every day that they’re not welcome.

Back in July I shared a post that referenced an amazing webcast by UX Designer Jasmine Orange on “Designing for the Ten Percent.” In that post the link was buried in a footnote, so I want to call it out here explicitly – if you made it this far into my post, you really want to watch this webcast. Jasmine’s premise[5] is that by designing for underrepresented users/communities/audiences/people you end up making better products for everyone.

I believe the same is true of tech in general – by building organizations, teams, and cultures that are welcoming to people who have been traditionally excluded, we build organizations, teams, and cultures that are better and more welcoming for people who have never been excluded. Diverse teams are stronger, more resilient, more agile, and more productive. Diverse cultures thrive and grow where monocultures collapse and die.

Why do I care? Does any of this even affect me directly?

Yes, it does.

On one hand, being part of a diverse team means that I will be more likely to be part of a successful team, with the financial rewards that come with success. On the other hand, I feel more welcome and more at home as part of a diverse team.

Still, it’s not about me, is it?

If you’re considering a role in tech and you’re not sure if you should apply for a job, do it. Even if you don’t feel like you’re a perfect fit, or don’t believe you meet every single requirement in the job posting. The white guys are going to apply because they know they below. You belong too, even if you don’t know it yet.

If you’re coming into tech from an underrepresented minority, you not only belong, you’re vitally needed. You bring something that no one else can bring – your background, your experiences, your perspectives – all the lessons you learned the hard way that an all-male, all-white team might pay an expensive consultant to tell them about after they’ve failed enough times.

Not every employer will recognize this value, but that doesn’t mean it’s not there, or that it’s not real. Some employers will judge every candidate against the “tech bro ideal” and will try to make every hire fit into this mold.

If you’re an employer, don’t be this guy. If you’re an employer, recognize the strategic value of having a diverse team. And recognize that this diverse team won’t happen on its own. Support organizations like Black Girls Code, because this is where your hiring pipeline will come from. Value the diverse perspectives that are already represented on your team, and promote them. Give authority and power to people who will hire diverse candidates. Give authority and power to people who look like the people you’re trying to recruit.

And if you’re working in tech today, please be be the person who notices. When you see someone kicking ass – doing an amazing job and demonstrating talent and potential to do more – be the person who says something. Even if you can’t see yourself in that person. Even if they don’t look like you and the rest of your team.

Representation is important, because it helps more people know that they can open that first door. Visibility is important, because it provides the opportunity for change and growth – visibility is what opens the second door, and the third, and….

Ok…

I started off writing a completely different post, but this is the one that wanted to come out today. At some point in the next few weeks[6] I’ll follow up with a post on community and how community is a key technique for increasing your visibility, but this post has gotten long enough, and then some.

Thanks for sticking with me – I’d love to hear what you think.


[1] I learned in 2014 when I first saw this video and fell in love.

[2] Underlying this false knowledge was likely the experience of growing up rural and poor, and not having a lot of opportunities as a child, or many experiences as an adult. It wasn’t until 2005 when I first travelled to Europe for a Manowar concert that my mindset started to change, but that’s probably not relevant to this post.

[3] Classified ads are what we called Craigslist before it was LinkedIn. Something like that.

[4] At this point I feel compelled to mention my friend Kathy, who actually got the job I applied for. I didn’t get the job, so I ended up taking a job as a bank teller. When the training center had another opening a few weeks later they called me back to ask if I was still available, and I said yes. True story. Hi Kathy!

[5] More accurately, this is my interpretation of Jasmine’s premise.

[6] LOL @ me, and LOL @ you if you haven’t learned by now not to trust any predictions of future output on my part. We should both know better by now.

Thoughts on effective communication

Early in my career I worked with an incredible network engineer. This was back when networking was a bigger part of my job, and I learned a lot from him[1]. But he was not an effective communicator. Any time we were in a meeting and he was presenting a topic I cared about, I needed to stand up, get closer to the front of the room, and focus exclusively on what he was saying, forcing myself to pay attention.

Because he just shared facts.

Page after page, slide after slide, minute after agonizing hour of facts.

arrows-2980845_640

This was before I knew about the value of asking questions, so I took the burden on myself, because I cared. Most people who could have gotten value from his expertise simply tuned out, or fell asleep[2].

Although this colleague of days gone by will always stand out as the exemplar of ineffective communication, I still see people every day who communicate by sharing facts without context, and without taking their audience into consideration.

Here are a bunch of things that I know and now you know them too!

Yeah, nah. When communication is simply a dump of facts, an opportunity is lost.

If you find yourself falling into this pattern of communication, please pause and ask yourself these questions:

  1. Who is my audience?
  2. What is my goal for communicating with this audience?
  3. What does my audience care about in general – what motivates them?
  4. Why will my audience care about what I am telling them?
  5. How will my communication motivate my audience to take action to meet my goal?

Or, as a colleague summed it up nicely in a chat:

“Target audience and value proposition. FFS.”[3]

You may be looking at these questions and thinking “that sounds like a lot of work.” I’d like to respond to that excellent-but-false thought in two ways.

First, asking yourself these questions is simply a habit to develop. It will take a little time at the beginning, but over time it becomes second nature.[4]

Second, choosing to not ask yourself these questions is like choosing the low bidder when picking a home improvement contractor. You save a little up-front, but you end up needing to re-do the work more quickly, and no one is ever happy with the results.

These questions apply to any form of communication – email, presentations and conference talks, personal  conversations, you name it.

For lower-risk, lower-value communication like a chat with a coworker you might ask yourself these questions during a conversation, as a safety check to help you keep on track. For a high-risk, high-value communication like a business review or product pitch or large presentation, you might ask yourself these questions many times over weeks or months as you define and refine the narrative you want to drive.

For the past year or so, my great-grandboss was an amazing leader named Lorraine. One of the things I loved about working with Lorraine was how she structured large-audience emails. Any time she sent out a newsletter or other message that would reach hundreds of people, she consistently included these sections at the top of the mail:

2020-08-05-10-57-47-549--OUTLOOK

  1. Big bold header so you know instantly what you’re looking at
  2. tl;dr section so you can read in 2 or 3 sentences the most important things in the mail
  3. Read this if section so you know if you’re the target audience for the mail

Every time I see one of these emails I am impressed. Lorraine is a communication wizard, guru, ninja, and I am in awe of her effortless-seeming skills.[5]

But… these effortless results probably come from years of mindful practice. As with any skill, you only get the results if you put in the effort. Why not start today?

P.S. While this post was written and waiting to be published, someone mentioned to me the Minto Pyramid Principle. I’d heard of it before, but I never actually knew what it was called, and now that I do know I’ve done some additional reading on it. The Minto Pyramid Principle is a communication tool that take a similar approach to the “know your audience” approach I’ve presented above. Unlike my random blog post, the Minto Pyramid Principle has stood the test of time – it’s been around since the 70s, and there are lots of different resources including books and articles out there to support it with training and information. You should check it out too.


[1] 20+ years later I am still reminded regularly that 90% of communication failures are caused by problems in the physical layer. Please do not throw sausage pizza away.

[2] Yes, literally fell asleep in work meetings. It was a running joke.

[3] Full disclosure: I added the FFS, not him. But it fits.

[4] Think back to when you were first learning the Farfalla di Ferro, and how you needed to think about every cut, every step, and every transition – and how today you could do it with your eyes closed.

[5] Lorraine is no longer in my reporting chain after a recent re-org, and you can be certain that I sent her a “thank you” message during the transition period. Some things are too awesome to not acknowledge explicitly.