DevExec & DevLead
Wednesday, April 27, 2022
Creating products is hard: it involves designers, developers, QA and a deployment story. While agile methodologies helped to accelerate the software development, other steps in the creation process are still lacking behind. How much friction does the interaction between various roles cause? Is there a chance to do better?
Join us to learn how to close this gap and speed up the software development process. Tapio and Maurice will discuss through case studies, based on their experience and findings from the Qt Company’s how to create an application framework that lasts for 25+ years and serves thousands of customers in more than 70 different industries.
When the agile manifesto was published in 2001, a wave of enthusiasm took over the developer community. Finally a decent, human-centered approach to development, full of common sense to replace the construction-inspired bureaucratic processes that were the state of the art at the time.
But as the development community became more professional and the size of digital projects grew, bureaucracy came back. And now with agile in its name.
As pioneers of agile, devops and lean, with 12 years of experience on hundreds of successful software products, we want to fight back against that bureaucracy and maintain the enthusiasm of the early days.
To do this, we will go back, together, to the agile manifesto to understand its core DNA. And then look at what research tells us on how we can scale it.
There is no silver bullet against bureaucracy... but there is 70 years worth of research on the topic, that we have experimented with over the last ten years and that we believe deserves much more attention.
We’ve all heard that it’s lonely at the top. For me though, having held both CEO and VP Engineering roles, I’ve often found VP Engineering to be even harder than the notoriously challenging role of CEO, and lonelier. For me, this was due to spending the lion’s share of my time translating between two completely disparate worlds - engineering and business. As the VP of Engineering, our peer executives see us as technical, while our teams on the other hand perceive us as business. Being the bridge between these worlds places us in a unique position to help our company succeed.
Over the years, I’ve found that the most valuable competency a great engineering leader brings to the role is being a great translator. An excellent tech leader will be able to provide much-needed context about the business to the developers, while continuously educating non-technical stakeholders on how software gets made.
In this session, I will share how to translate engineering concepts to execs, why it is important to provide non-technical leaders with more technical detail than you’re giving them now, and which metrics to share with your business every week. You’ll leave with actionable tips for achieving alignment with your business, negotiating for more headcount and non-functional investment, and having more constructive conversations with your CEO. Plus every attendee will get a copy of the engineering metrics scorecard I share every week with our exec team.
Once upon a time, developers wrote software and threw it over the fence to operators, who had to worry about deploying it and keeping it running. It was a mixed blessing: they could concentrate on providing value to the business, but they also had no control over the systems on which they worked, leaving them at the mercy of overworked operators who would get them what they needed as soon as possible, which might mean days, weeks, or even months.
Now we have DevOps, and developers can, in many cases, take advantage of self-service models and get what they need when they need it. Which is great. But now they have to worry about things they never had to think about before, like network setup, or security, or finding enough hardware to set up that dev cluster.
In this talk we’ll look at the top 7 things a developer should be able to ignore in favor of providing actual value to the business.
Although leadership skills have been analyzed for so long, there is something in the way we choose and raise our technical leads that defy all laws. We often think that the brightest and most creative person in the team will eventually become a technical lead, which actually happens in most cases. The exciting part, though, the process of becoming a technical lead starts when we actually take over the role. What seemed to be a gratification for excellent results can become a long list of failures if you don’t really, really prepare for the challenge. Luckily we can learn from each other’s mistakes, so join us to touch some hot spots in the technical leadership journey.
OPEN TALK: Principles and Practices to Encourage “Responsible” Machine Learning in Your OrganisationJoin on Hopin
Many organizations are using machine learning models to make important business decisions - including decisions about which candidates they hire. However, when these models include bias, there can be significant consequences for both the organization and its job candidates. This session will define “responsible” machine learning and why it should be prioritized, when incorporating machine learning into business decisions, using hiring as an illustrative example.
Thursday, April 28, 2022
Engineering metrics have a terrible reputation — and for good reason.
That’s because most early attempts of measuring engineering performance were largely focused on tracking the activity of individual developers with metrics like lines of code, rework, and code churn. Yet, these metrics have no proven correlation with business performance. And in fact, they’ve done nothing but alienate developers, create mistrust, and misalign incentives.
But what should engineering teams be measuring instead?
In this session, we’ll walk through the seven persistent misconceptions that are still preventing engineering leaders from using data to improve their teams’ satisfaction and productivity.
We’ll also discuss the three areas of engineering you should be measuring if you’re looking to speed up software delivery without sacrificing culture or quality.
CI/CD seems to be simple. But let's take a step back, and look at it from a helicopter view.
Let's think about the design CI/CD processes for the project, team, even organization. Let's go through "architecture of CI/CD". What areas should we cover? How to talk with Stakeholders about CI/CD when we design the backbone of DevOps driven Organization?
This presentation includes industry benchmarks from 2,600 dev teams collected from January 2020 through June 2021, all of the data and citations from my research, multiple case studies from well known Israeli start-ups like Unbabel, Intsights and BigID, and tips for improving PR size, cycle time, MTTR, change failure rate and deployment frequency.
Notes: In my role as CTO of LinearB, I help engineering leaders improve through data and metrics. This presentation is NOT in any way a sales pitch for LinearB. In fact, the name of my company will only be mentioned twice in the session - once when I introduce myself and again when I reference how we collected the data for the study. But, that said, LinearB has allowed me to become a top expert in engineering metrics and I have real-life experience in how the Accelerate DORA 4 metrics are used by real dev teams around the world.
Shifting Application Security Left and into the hands of developers has been a topic of discussion, but remains just that, a discussion. Legacy solutions in the market are not built from the ground up to enable this and achieve DevSecOps. In this session we will discuss the key features that your AppSec testing tools need to enable shift left, or shift everywhere, to empower developers to detect, prioritize and remediate security issues EARLY, as part of your agile development and unit testing processes, without slowing you down. The talk will include specific examples from leading organizations that have deployed these solutions, the business impact they have achieved and the steps you can take to achieve the same, across your applications and APIs
Collaboration within open source projects is becoming increasingly important for companies, but it can be difficult to strike the right balance between the needs of the company and the open source project. This can create friction and put significant pressure on employees who participate on behalf of their company when the needs of the individual, the company, and the community are not aligned. This talk will focus on ways to create this alignment between individuals, companies, and the community to help all of us be successful together.
Communities are a critical component of open source projects, and the way that people participate can reflect positively or negatively on the person and organization that they represent. The majority of work in some projects, like Kubernetes, is done by people working for a wide variety of organizations, and the success of many projects rely on participation from these companies. The advice in this presentation will help people, and the organizations that they work for, improve their participation in open source communities.
The talk contains three major sections:
• Dynamics of collaboration in open source projects between individuals, companies, and communities.
• Strategies for participating in ways that will benefit your company, your employees, and the community.
• Tips for being a good corporate citizen as you contribute to open source projects.
We love numbers, don’t we? If we are good managers, it’s natural that we want our people and our teams to get better. Incremental improvement is the mantra of agile philosophy and what better way of doing that than measuring things? Velocity, bug counts, MMTR, cycle time etc. However, there can be a darker side to metrics that we can easily slip into it if we are not careful. What starts off as a way to encourage and motivate a team leads to behaviour that is counter to what we want – stifling innovation and creativity as adherence to the metric becomes the prime driver. In this talk we look at common metrics we measure as tech leads, what they should and should not be used for and how, by developing a closer relationship with our team, we can dispense with metrics for something less harmful and more effective.
As more and more companies are building tools and platforms that enable developers, the rise of DevEx programs continues to accelerate in almost every corner of the software world. In every one of these new programs I have seen two key mistakes that almost every organization makes. Some recover from them and some do not, but both of them can be avoided before you make them. Join me as I talk about what they are, why they happen, and how to fix them before they become a problem for your program.
If you're building a product or service for developers, documentation can easily become a second class citizen: something to tackle once we get more funding, more headcount, or more traction. In this talk, I'll explain why that is a big mistake, and talk about how to build your documentation into a strategic asset.
When you are building for developers, documentation is critical from the very top of your funnel. That's because your documentation is content marketing: it contains the answers to questions your prospective users are asking.
Documentation defines your product, because developer psychology eschews glossy brochures in favour of nuts and bolts: your docs are how they decide whether your product creates value.
Documentation is your user interface: When a developer is using your product, they are staring at either their code or your documentation. Your docs are your brand and your user experience.
So how should we write it? I'll break down the different types of documentation: their audiences, how they differ, and how to make them work together. I'll also describe how to avoid the classic trap of shipping a pile of API documentation and calling it a day.
Finally, I’ll talk about how our users and customers can show us the way. By using our community - and avoiding thinking about this as “a problem for the DevRel team” - our users will show us where we can do our most impactful work.
Wondering what it takes to build and lead a global, remote engineering team? Hopin’s VP of Engineering will share his insights on how to support your global remote team to quickly, efficiently, and successfully build products that meet customer needs and stay ahead of the competition.