Daniele Bernardi on Working with Non-Technical People and Getting Recognition Right

Dev Chats is back for season two! This is a series where I speak to an awesome developer or techie every week or so. You can read more here. Let me know if you know someone awesome I should chat to next.


Introduce yourself! Who are you? Where do you work?

Hi! I’m Daniele and I am a Senior Partner Engineer at Twitter. I work in the Data Enterprise Solutions team to help our customers power their business at scale using real-time and historical social data.

Who or what got you into programming?

When I was 8, my cousins lived close by. One of them had a Commodore 64 which we used to play with. Anyone with a Commodore 64 fetish will remember the fuzzy colors from any loading screen – simply watching that would have made my day.

Another of my cousins had a Philips MSX VG-8020. Despite being a much more powerful machine, this computer didn't enjoy the same popularity as the Commodore 64. (Fairly, back in the days, it was dubbed "the poor man's Commodore"). MSX was a platform developed by Microsoft, so it would ship with a fairly standard implementation of BASIC – the same you would find in the first PCs. This would theoretically allow you to write a BASIC program for an Intel 8088 and run it seamlessly on the Z80 processor you would find inside the MSX.

The MSX is probably the first computer that made me realize I wanted to build things. I remember staring at its blue screen and typing what in my mind would be my first computer program:

"Draw: watch face"

To which the poor BASIC interpreter would hopelessly reply:

"Syntax error"

The computer came with an interesting BASIC manual; after my cousins were done playing Gunfright on the MSX, I would reset it so I could summon BASIC and try to type a few lines of code. Running the finished code would be the most rewarding feeling; I think that's when I discovered my passion. I would think of my cousins as the people in front of the screen. I wanted to be the person behind the screen. (I was a weird kid, I know.)

But I think the true deus ex machina behind my passion is my dad. He nudged me towards software development probably without both of us ever realizing that our common interest would later determine my career. As a power plant supervisor, he would monitor the generator's vitals and operate on their settings directly from a computer screen. His work computers would be equipped with apps like Lotus Symphony, which contained a quite sophisticated automation macro and formulas environment. Being the inquisitive tinkerer he is, I think he immediately became intrigued by that software and its infinite applications. By 1994, we had our first PC – A fast, shiny, (almost) new Intel 80386. Officially, that was my first communion gift. We knew that was my dad's gift to himself. He would use Microsoft Excel for Windows 3.1 and the aforementioned Lotus Symphony to compute many aspects of his life – including his shift roster and his retirement plan projections. He would even devise a set of complex macros that would run overnight to generate lottery numbers likely to win (he did win at times.)

When he brought that computer home and placed it on our living room table, he would finish his installation by posting a sticky note over the computer's case. The note would read:

ABSOLUTELY DO NOT TYPE FOR ANY REASON:

• FORMAT C:

• DEL \*.\*

• FDISK

Sadly, I ran them all, wiping all of his precious work. To this day, we still don't talk about that incident.

How do you find the balance of client interaction and coding as a Partner Engineer?

Juggling client interactions with coding is definitely trickiest part of my job. Many companies do not have a clear separation between inward- and outward-facing duties. My best approach has been to ruthlessly block my calendar to have at least 20-30% of my time dedicated to internal tasks, including building products and writing documentation, when that would make sense. Throughout the end of any given quarter, my time would skew almost exclusively towards client interactions, so I could help the Sales organization by providing solutions, architectural blueprints and technical guidance almost in real time.

There are also times where internal time intertwines with client facing interactions; this is the case when clients require a custom solutions or technical guidance (for example, when I need to review an integration). In this case, I allocate time to chat with my client's developers, and reserve internal time to investigate and prototype solutions or fixed (if there's a bug). This way, my internal time will be sandwiched between two short time windows of external communication – forcing me to prioritize and timebox my technical tasks and to be diligent about updating the client about my progress.

You often work with a lot of non-technical people in your role, how do you find that and what are your tips for an effective working relationship?

I absolutely love working with non-technical people; I find that aspect of my job almost addictive. I have to translate lines of code into real-world examples in English, which is not my first language. It keeps my mind active and it's what makes me so passionate about this role!

The ideal relationship with non-technical people is built on empathy, technical leadership and trust. When non-technical people are involved in a technical project, they may feel overwhelmed by the amount of details they think they won't grasp. It's crucial that you understand the reasons why they feel uneasy about the project, and it's imperative that you acknowledge their feelings. Perhaps they feel their technical background is not as strong as their peers'; or they just need someone to untangle some of the most intricate jargon, and merely act as a translator between code-speaking and language-speaking people. Regardless of the reason, empathy makes all the difference between you as an engineer with a prowess for client interaction, and technical project manager or software engineer.

Bringing a certain degree of reassurance to the conversation will also open the door to smoother communication and mutual benefits. For example, non-technical people can help you navigate a big organization, but this can only happen when they feel certain your technical leadership is sound. I'm not afraid to say I struggled with this aspect at the beginning of my career. I thought technical leadership would simply mean displaying your knowledge by painstakingly listing all the details in a project, but I soon found out that aspect is actually perceived as overzealous. Technical leadership is really about using your best judgement to condense the most difficult aspects into a straightforward statement; it also means hiding details you know don't require broad consensus among the key stakeholders of your project. Given their experience and background, Partner Engineers can easily assess timing and effort of any given task, and can create a smooth narrative to reach broad consensus in a large project. As a Partner Engineer, people trust your judgment given your ability to empathize with your team and your sound technical ability combined with your soft skills.

How do you think the ad industry will change over the coming years, and how might that affect your role?

Social media shook the ad industry from the ground up. The mobile era obviously brought another seismic wave of change to the industry. It created a whole new ecosystem – app development, which in turn became an entire new advertising vertical. Still, most ad platforms are struggling to identify a well rounded mobile strategy. As we're still living this era of change, my job has a lot to do with measurement and strategic solutions.

It's quite difficult to predict the future, but in this industry, performance and privacy will determine the conversation both technically and broadly. Regulations such as GDPR now require marketers to think carefully about their data architecture and flow. Look where the measurement industry is going and you'll find an answer.

You recently went back to an individual contributor role after a period in leadership. Was that a hard decision?

Absolutely not. It's interesting – We see leadership as a step forward, but to me it's a different job that you perform in parallel with your usual duties. Having a Senior position in the team, I can keep being a mentor, but more importantly, I can keep learning from my team. In general, sometimes it makes much more sense to place a bet into an expanded role for a more prominent company, which is exactly why I chose this job. It's important to talk to your manager about your desired career path (we talked about this extensively).

What have been your toughest lessons to learn in your software career so far?

I have two: always get rid of technical debt, and never settle for a company that doesn't see your true value. It's funny, sometimes the two things are intertwined.

Technical debt accumulates for a number of reasons, but if we dig deeper, companies that can't afford to repay it (or even worse, they deliberately choose not to) are those who struggle to make a significant impact in their industry. When this happens, they fail to attract great talent, and their leadership seems clueless when to fix this lack of recognition. You may end up working in an Engineering team who consistently fails to make a good case for updating your company's stack. Meanwhile, the CTO and/or the head of Engineering may delay these key infrastructural choices to accelerate on shipping more customer-facing deliverables. It's not sustainable; in my experience, a pattern like this will tank the company without sinking it completely. It's a slow, painful death.

Since companies are made up by people, employers who invest in their technology are the same who invest in their people. There are two types of companies: those who think you define the company's success and everybody else. Just like respect, recognition is binary: it's either there or it's not. If your impact is only partly acknowledged, then it's not acknowledged at all.

Recognition doesn't cost money and it takes little time, and this is why is oh so frustrating to see so many employers not valuing their people as they should. The vast majority of the companies out there believe recognition means creating a fabric of social events or activities, all lamely named by bastardizing your company's name. Company Acme, Inc. would invite you to their "Acmagic" Party (it's their party, not your party) – does it sound familiar to you? And what's so "acmagic" about it anyway, if it's just another happy hour?

Leadership could spend 5 minutes of their all hands to acknowledge your hard work. It should come naturally, it should be heartfelt or at least sound empathetic. "I just want to remind you it's a privilege to work with all of you" would do the trick.

Instead, their statements sound tone deaf and forced – even worse, sometimes they are read out of a piece of paper in a form of a lame poem, or they're presented to you as an award you know you're going to get anyway if you wait long enough and don't complain too much. But guess what: this is not about competing; this is about being in the same company for the exact same reason, and the reason is you are absolutely amazing at what you do. I felt my impact was more recognized at places where they didn't give awards away than on places where I did receive one or more of those.

What would be your number one piece of advice for a successful software career?

Always stay focused and always be hands-on. Time really flies when you're focused on building something. Sometimes I realize I found a level of isolation I didn't believe I was able to achieve. I'm sure everyone has their own advice. Soundproofing your environment works really well for me. Investing in good noise-canceling equipment really helps you reduce a lot of distractions (sometimes I just turn my headphones without playing any music.)

To bring this to a more abstract level, staying focused also means keeping in mind the broader context of our work.

Lastly, as software engineers, we should always be grateful for the gift of curiosity that allows us to break down a problem into smaller blocks we can solve individually, so that they can come together as a solution. Applying this gift to our day-to-day helps a great

Finally, make your shoutout! What would you like the readers to go have a look at?

You can check me out at @i_am_daniele. I am mostly a Twitter lurker but I do post my work from Before Today, where I cover recent tech history before it gets lost. What did the world look like before the iPhone? And how did we got into the social media revolution? I think the journey to the present has been so crazy it was worth telling it.

Permalink

Comments

[Flo Comuzzi]

Thanks for this post. It really caused me to reflect. I wrote up a short response here: dev.to/floinnyc_/a-technical-leade...