The Art of Engineering with David Blackman
Discover David Blackman's engineering journey from Google, Twitter, Foursquare, Radar, and Notion. Gain insights on leadership, project lessons, and expert advice for tech enthusiasts.
In the ever-evolving, fast paced world of engineering, where adaptability and specialization stand as the cornerstones of success, David Blackman emerges as a true luminary in the realm of fractional engineering.
His career, deeply rooted in the world of engineering, serves as a beacon of the transformative power that technical expertise wields in propelling innovation and surmounting intricate challenges. David's remarkable journey embarked from a fortuitous turn of events at Google, where he was thrust into the dynamic realm of search engines and maps. In this vibrant ecosystem, he delved headfirst into the intricate universe of geospatial data and distributed systems, forging a profound connection with the very heart of digital landscapes. As time passed, he orchestrated projects that reverberated throughout the tech ecosystem, one of the most notable being the development of a pioneering geocoder at Foursquare. This achievement not only demonstrated his technical prowess but also galvanized a vivacious open-source community that thrived around it, a testament to his ability to inspire and lead innovation.
- Fractional Staff Engineer
- Engineering Manager
- Fullstack
- Team Building
Over 15 years of Geospatial and Search experience at leading companies
Beyond his technical wizardry, David's artistry extends to the meticulous craft of internal tool creation, a skill he nurtured since his formative years, when he embarked on a journey of exploration and mastery with Linux as his guiding star. In David, we witness a rare fusion of technical virtuosity and leadership acumen that renders him the quintessential choice for any organization seeking a fractional engineer capable of steering the ship of innovation and conquering multifaceted challenges with grace and dexterity.
A Deep Dive with David Blackman
1. What is your specialty and how did you gain mastery over it?
I'm half-and-half - As an engineer, I've specialized in search engines and maps. When I first started at Google, the company would look deep within a college new hire's soul and assign them to a completely random team, which in my case was Google Maps in NYC. There I was exposed to world class engineering, discovering the joy of working with geospatial data and the beautiful distributed problems of search engines. Since then I've worked on similar projects for about half my career, including building out a geocoder while at Foursquare that had an active open source community around it for a bit. I've spoken at mapping conferences. I've kept up with developments in the world of search relevancy and ranking, including vector search by talking to industry leaders and following conferences and whitepapers.
Another specialty of mine is building internal tools, this is something that comes from having been messing about with Linux starting in high school (rather than, you know, partying) at a time when much of my life was lived on the commandline, and the idea that I could customize the computer to meet my needs was a joy and a necessity. Throughout my career I’ve observed where myself and other engineers are losing flow, complaining, where they’re constantly getting stuck, and carved out time to build the custom tools that no-one knew we needed until it got built and then we couldn’t live without.
As a leader and coach, I draw heavily on both my personal and professional experience. On one hand, I’ve experimented with different forms of therapy in my personal life and on the other, I’ve read numerous books on managing teams and engineers, along with having spent a long time reflecting on my career. Combining all those inputs and more allows me to hear what coping mechanisms, self-doubt, self-limiting thoughts are holding engineers back from not just what the company wants them to be, but usually, more importantly and more effectively, what they want to be. I help many engineers develop better hygiene around their work that allows them to get to level of productivity and craft they desire
2. What was the most successful thing you personally have built/worked on/did?
The most successful thing I ever worked on was Twitter Moments. The project grew from two disconnected hack week projects, to a 20+ person team and the number one company priority for that year. I grew from being one of the first engineers, to managing a distributed team of engineers across four locations. The project had that blues brothers energy of “we’re getting the band back together” - I created a safe and engaging space for some extremely senior and burned out engineers, who went on to reinvest heavily in their careers at Twitter. I encouraged rapid iteration and collaboration between designers and engineers. The project started at a time when it felt like Twitter couldn’t ship anything, and we were so proud to build an entirely new, highly polished, exciting experience in the app.
I did everything on this project from writing some of the initial code, advising technical decisions, recruiting both internally and externally, creating processes for working with internal content curation teams, developing short and long term roadmaps for the product. We successfully kept the team together for quite a while, continuing to iterate on the product after fearing the curse of not being allowed to continue past the initial launch.
We hit our launch date without crunch, we had in place trust & safety from day one. We pulled in external consulting engineers for isolated parts of the project when we needed more firepower to get tooling built. And, people liked it! It served a need for users as well - wanting to actually be able to figure out “what’s happening” on Twitter in a way that they couldn’t before.
Separately, I built a piece of immersive audiowalk theater a few years ago. This was entirely a personal project when I was taking a sabbatical after Twitter. In truth it is the project I’m most proud of because it had so much of me in it, was so unique, and so meaningful. I worked with two theater makers on it - we found a good working strategy where our producer could translate between my technical expertise and the director’s theatrical vision. I also rediscovered during the process that I knew how to write - putting in about a third of the script, and some of the most memorable moments. I devised a way to record stories that felt like the audience was watching someone use their phone - the pieces that came out of this were so good that they made me cry - even though I wrote and directed them! The script ended up being semi-autobiographical for both myself and the director, so there was a lot of us on the page. People loved it - I still meet folks who said it was one of the best examples of that form they’d ever seen. It touched people - I invited a friend to see it who said she couldn’t talk to me after because she was so emotional, but wanted to give me a silent hug. It was exciting and different and something I worked nights and weekends to build. It integrated everything I love - user generated stories, mapping, theater, playful improv games, intimate phone apps.
3. What was a mistake you have learned along the way?
I think it’s threaded through here, but it’s the counterexamples to most of the things I list in the next section.
(I’m so self critical, this could be a whole book)
The biggest overall one is not thinking harder about who I want to be at the office - showing up to be liked, rather than to be productive or successful. I have had points in my career where I came off as messy, emotional, untrustworthy. I thought my job was to play the court jester, to be able to move up and down the organization and be a release valve and translator. But that wasn’t my job - I was hired as an engineer, and my incorrect self-perception of my role, and the reputation I picked up in playing it - became liabilities for me that prevented me from being as successful or impactful as I wanted to be.
Relatedly - joining companies because of, and believing in, "the romance" - the idealistic vision of what the company wanted to be. This caused a cognitive dissonance in me that I was really sensitive to.
Which is why I really do want to help people think harder about who they are, and who they want to be in a corporate setting.
4. What tactical advice in your field of expertise do you have for someone?
Here’s notes from a 1:1 coaching session I had with a brand new (female) engineer right out of boot camp to give you a sense of my style and advice
(Junior) Engineer career advice
- For younger engineers, I really encourage them to practice discipline, to practice working - it’s so easy to lose the ability to focus for long blocks of time with all the notification distractions we have, and it’s so hard to regain that skill. Building good habits early on in a career makes everything so much easier. Do all the boring things that the HBS blog posts tell you to - start your day with a calendar, keep a todo list, wrap up your day with a self-summary of what you did. Use tools to focus, etc.
- Additionally, I advise them to invest in / deeply learn their tools - I use the metaphor of walking into a woodshop - every woodshop is a custom built environment for someone to do their best work, full of custom built tools and jigs to enable work to get done. This is so obvious in a physical trade, but we tend to take it for granted in our virtual/knowledge trade. Building the right environment serves so many valuable purposes - it keeps us in flow state longer, and it feels like a gift and investment from our past selves to our futures selves, it creates a positive feedback loop.
- I find that a lot of the engineers who seek me out for mentorship are ones who are very sensitive and thoughtful people, who find that there’s a disconnect in the corporate environment with how they want to operate and how the system wants them to operate. Lately I’ve been encouraging folks to not bring their whole selves to work, but to consider how they want to present themselves - this has positive external and internal effects. Showing up to work with the presentational mindset of “I am an organized and thoughtful person” allows us to embody that better than showing up as “I’m messy and zany”. It’s also usually closer to how we need to operate in work settings.
Advice as a manager
- It’s easy to be a well-liked manager, it’s hard to be a good one
- A mediocre manager focuses on managing down, keeping their reports happy
- A good manager focuses on managing up - making sure the team is working on the right things with alignment from execs, making sure they can explain well to the team and the company why they’re working on what they’re working on, and why they’re deprioritizing some things that might seem like “obvious” projects.
- This ensures that the individual members of the team have impactful work to do that will help them in their careers both at the current company and in the future
- Touchy-feely conversational 1:1s should not be the default, that’s lazy. 1:1s aren’t status updates, but they should mostly be conversations about work. Too much focus on feelings means there’s misalignment with work. Also, it’s usually a symptom of not coming in prepared to 1:1s with topics to discuss, and might also be a sign you’re not doing enough during the week to get status updates and have casual conversations.
- Figure out what kind of a manager you are - are you purely a people manager? In which case, defer lots to your TL and make it clear you don’t need to be a blocker for every major decision. Are you more of a TLM or manager who wants to have engineering input? In that case, make yourself available for lots of casual daily informal chats so you’re not a blocker - and also make it clear what the division of labor is between you and your TL / senior eng.
Engineering process / development advice
- Invest in tooling, anything you do more than a few times a day, build a tool for it
- Document the processes, even if it’s just a one-person project - it will be easier to onboard in the future, as well as you will thank yourself if you need to put down the project and come back to it (for instance, I try to have a “run.sh” in every personal github repo I make)
- Comment every function if you can
- Testing. It’s always worth it. Eat your vegetables. Even one giant end-to-end test. Make it automated, make it stable.
- Use a style guide - even on a one person project, think of it like Steve Jobs and his black turtlenecks - it’s just one less decision you need to make every minute you’re writing.
- Don’t be afraid to buy not build, but be prepared that using external systems can require a large time investment in reading docs and experimenting that doesn’t feel like “productive” time
- Try to use simple, well understood, widely used technologies.
5. What advice would you give to someone who wants to build out a team/product/service in your fractional function?
I have one constant across all of these things, and it’s “be honest about what you’re building and why.” I believe that companies are constantly hamstrung by the cognitive dissonance caused by misalignment between stated vision and what’s actually being worked on.
As an example, Foursquare said it was for “making cities easier to use” when in reality, by the time I left, the product was for finding restaurants and bars. We wanted to sell ads and promotions to small businesses, as part of the diversity of cities we all enjoyed, but the real money was in large corporate partnerships. All this led to people not knowing what to build (should we build for the vision/romance, or the practicality/business), and feeling constant demotivating disappointment in what we were building. If we were more honest with ourselves, it would have made it easier to build the best version of the thing we were actually working on than fighting it into what it wasn’t.
I also think that companies/founders/execs often fail to be honest about the mission in another way - 99% of the time, the primary mission is to make money. It’s not about “empowering people with software tools.” Finding a way to be honest that everyone is working in a for-profit business that needs to make profit-motivated decisions
—
A more tactical belief I have is: Don’t squander your superusers! They are not a renewable resource!
Make sure to allocate some resources to your top 1-10% of users
I saw this at many companies I’ve worked at, where we had incredibly passionate communities of people who were doing a ton of free labor for us as well as even more free marketing, but at some point, as we grew and market/growth pressures came to bear, we built less and less for them. It’s much harder to grow new impassioned ambassadors for a product than to keep the existing ones happy. It’s not enough to give them t-shirts and stickers, they want features in the app. And even if those features are only for a tiny percentage of users, those are often the users who are driving usage of others or adding content to the system.
Key Takeaways
- Embrace Serendipity for Career Growth: David's journey began with a serendipitous assignment at Google. Lesson: Don't underestimate the power of unexpected opportunities. Sometimes, the most significant career advancements come from embracing the unexpected.
- Cultivate Technical Expertise with Passion: David's specialization in search engines and maps stemmed from his passion. Lesson: Encourage candidates to pursue areas they are genuinely passionate about. Passion fuels dedication and drives expertise.
- Foster Open-Source Communities: David's success with open-source projects highlights the importance of community building. Lesson: Seek candidates who can build and nurture communities around their work. This fosters collaboration and collective growth.
- Innovate with Customized Tools: David's knack for building internal tools improved team efficiency. Lesson: Look for engineers who identify workflow bottlenecks and create tailored solutions. Such individuals can optimize your team's productivity.
- Balance Technical Mastery and Leadership: David seamlessly transitioned between technical and leadership roles. Lesson: Recognize the value of versatility in engineers. Those who can lead while maintaining technical excellence are assets to any organization.
- Invest in Personal Growth: David's commitment to self-improvement and learning from experiences is admirable. Lesson: Encourage candidates to invest in their personal and professional growth. Continuous improvement leads to greater contributions.
It's Time to Go Fractional
If you're seeking a fractional engineer with a proven track record of technical excellence and innovative problem-solving, look no further than David Blackman. His wealth of experience and leadership insights can empower your organization to thrive in the ever-evolving tech landscape. To explore how David can contribute to your team or project, visit his profile or head to explore for all your fractional hiring needs. Don't miss the opportunity to leverage David's expertise to drive your organization's success.
