DevExec & DevLead
Wednesday, December 9, 2020
It’s critical that dev leaders continually inspire and better their teams for continued innovation and excellence. Meredith Johnson did exactly that when she helped lead process and cultural transformations that allowed for the evolution of Blackbaud’s technology strategy from a lagging, on-premises leader to an agile development model with solutions implemented on Blackbaud SKY®, the company's platform for social good cloud innovation, in just eighteen months.
Meredith Johnson's strategy was driven by the mantra “Be Brave.” She understood that bravery leads to innovation, innovation leads to company success, and company success leads to more company success.
Meredith will share the keys to managing dev teams to increased innovation and success, including:
• Creating a “safe” environment for productive disagreement
• Giving teams problems to solve, not solutions to implement
• Creating an environment of autonomy, mastery and purpose
• Celebrating failing fast
• Pivoting quickly
She’ll also share the four biggest lessons learned along the way, including:
• The hard stuff isn’t the code. It’s the culture.
• Reiterate and stick to your principles.
• Be ready to fail.
• Code wasn’t our secret sauce.
Building a healthy development team has never been more challenging for start ups, but this is not another talk about hiring. It is about necessary endings. Being a newly born startup in Germany’s startup capital in need of fast results, we have often hired too fast but rarely fired too slow.
This talk will not prescribe the right way of growing an engineering team because small startup founders are beggars and not choosers when it comes to staffing. It is about a balanced trade-off. Motivating and shaping software engineers is a no-brainer, however, letting people go has never been popular thus crucial to the health and growth of the team.
Hiring developers in Germany’s start up capital is hard, but as the CTO, it’s one of your most important tasks. Startups in need of quick results hire fast and sometimes this leads to making a less than ideal hire. Successfully navigating this circumstance is difficult as you seek to balance: ensuring your team culture is healthy, developing your juniors, managing people out and when need be having tough conversations and letting people go, while maintaining a good relationship.
How to Become a Great Developer: Case Studies of How Individuals Rose from Nowhere to Become ExpertsJoin on Hopin
After mentoring many developers over the years, I summarized the advice into a trending article on LinkedIn. Here are case studies of how individuals rose from nowhere to become experts.
Thursday, December 10, 2020
Have you felt frustrated by your team's speed of execution? Have you asked yourself, perhaps in the middle of a sprint planning session: Are we stuck?
Why do some teams seem to work faster than others? Why do some people perceive a team as too slow, while others consider the same team fast enough? And engineers on some teams appear to be more satisfied and more motivated than those on other teams; why?
Engineers don't lack motivation -- it is systems that fail to create an environment for engineers to make magic. In this talk, I’ll lay out a step-by-step guide for managers and ICs to ask the right questions towards this problem.
Alignment: Are the team’s goals and metrics aligned with the business? Is the team aware of broader priorities and constraints? Is there agreement around when to optimize for user-visible features vs technical debt? Is there alignment around what exactly the team owns?
Doing Too Much: Is the team keeping too many projects active at the same time? We’ll talk about how to identify if this is happening, and how to use metrics and models to choose what to prioritize.
Thrashing: Big and frequent changes in priority can make engineers take the priorities themselves less seriously— but such change is a reality in a fast-growing company. How do you reduce thrashing as well as increase adaptability to change?
Deep, slow projects: Some projects simply take a long time. This is especially true for infrastructure work. In this context, it’s important to demonstrate value early— engage with users, go deep before going broad.
As a manager or lead developer, this talk will give you a playbook to analyze and work on your team’s engineering velocity— and ultimately, to create an environment where people work together at their highest potential.
o your company just took a round of funding and you’ve been asked to rapidly grow your engineering team? Congratulations! This is an exciting challenge. It can also be daunting. You’re in for a lot of hard work, a lot of organizational changes, and the satisfaction of building an amazing new team. I’ll share some experience and advice from being given this challenge multiple times at both large and small companies.
Who is this for?
My advice will mostly focus on growing teams of ~10 to teams of ~40, but much of the advice applies to any serious hiring push regardless of current team size. The people who will get the most out of this are managers of multiple teams, VPEs/Director’s of engineering at smaller scale startups, but also people that are part of an interview panel on a fast growing team.
Logs are ubiquitous and indispensable. They are arguably the most important tool used by software engineers in our day-to-day work. In development, we use them to mark key points in our code, so we can peek into its execution (without using a debugger). In production, they serve as a way of understanding software execution in the real-world, providing immense value at both the macro and micro levels; they can be used to diagnose systemic problems, which affect your entire user base, but also to trace the journey of a single user, thus allowing you to provide individualized support.
Unfortunately, most companies are not taking full advantage of logs, because they fail to see what logs really are: a source of rich, real-time event data. In this session, we will explain how the Observability team at Brex unlocked the power of logs by allowing other teams to access and build on top of structured log streams. This was accomplished by (1) designing and implementing a super-powered logging infrastructure, which delivers log messages to multiple consumers in near-real-time, and (2) creating a strict log schema as well as a schema-adherent logging library to make the underlying data useful and coherent.
We will also deep dive into a particular use case: powering the alerts used by our Fraud team to identify suspicious behavior.
Your first time as a manager is not easy. You say some wrong things, make a few wrong decisions, and face lots of uncertainty. Being a great developer doesn't guarantee that you can help others be better developers.
This talk is about what I learned after going from a senior engineer in a team of three to managing a team of seven engineers. I will focus on the things you can do to prepare yourself if you are making the same transition, and the things a senior engineering leader can do to help someone in that transition.
Well written instructions, informative comments throughout code, clearly scripted screencasts, and smart information architecture can take complex code and make it accessible to new developers. In the age of code sharing, this can be imperative to teaching the next generation of developers, passing along your code to successors, and help you better understand your own work.
When I was an engineer, helpful READMEs and other docs created by my colleagues were crucial to quick onboarding and coming back to old products. Now, as a full time technical writer, I rely on our engineers to be able to concisely explain how products work. From these experiences, I feel it is essential that everyone feel empowered to write documentation, not just the technical writers.
In this talk we’ll discuss:
+ Why writing docs is important for engineers
+ Understanding your audience
+ Optimizing for the deliverable: READMEs, code comments, tutorials, release notes, and more
We’ll also cover some tips for communicating about your past work to your future self.
In an increasingly digital and automated industry, we must consider if full service financial institutions (such as J.P. Morgan and other large Banks) will continue to provide an end-to-end user-experiences for its Clients - a continuation of the “white-glove” service of institutions’ heritage. Or, will a more interconnected financial landscape lead to the financial institution being removed from the end-to-end experience, and instead focused on a core set of functions and components that live within an independent and de-centralized ecosystem? In more colloquial terms - Will the Digital Bank of tomorrow be more like Apple (providing the end-to-end ecosystem across the user experience), or Microsoft (steadily focusing on platform-as-a-service offerings across both native and competitive ecosystems)?
For market constituents in the financial services industry, it is neither common nor advisable to service all financial functions from a single institution. Given this inherent fragmentation, it’s unlikely that a single institution can provide the end-to-end user experience regardless of ability to innovate and compete in the future. With acceptance that the digital experience, as competitive as it can be, is unlikely to be exclusive amongst market participants, the industry will invariably head toward the aggregation and commoditization of business functions.
Not only is the nature of the global capital markets landscape changing, so is the nature of market participants. For example, according to a 2018 report by Greenwich Associates, technology spending is quickly increasing its share of overall buy-side trading desk budgets, with a 20% shift in the past three years alone. According to the report, firms are clamoring to access electronic trading venues, and a big driver for increased technology-spend is the need for more relevant data and the analytics to put that data to work. This trend is across all product areas, and is a “secular trend” unlikely to end soon.
The role of the Technologist at our Clients, once a supporting function to a traditional front-office discipline, is now a key constituency that must be satisfied in delivering digital solutions. The chief technology officer, head of digital, or data-scientist is today making decisions about platform-connectivity that hold the keys to commercial objectives in the future. The Technologist’s user-experience is the Client experience, for Technologists are the “creators” of digital solutions.
Financial Services organizations must provide a curated experience to these “creators” of digital-solutions, and to promote the connectivity required to be a beneficiary of the emerging competitive landscape. Standards, policy, and process for providing technical services should be structured as components of the overall client-experience.