This article is based on an interview with Kubernetes co-founder Brendan Burns who appeared on the Dev Interrupted podcast.
The success of Kubernetes was never preordained - it took years of work.
While today it has grown to be one of the largest and most popular open source projects and become the go-to API for building cloud-native applications worldwide - it almost wasn’t even open source.
Since its start in 2014, Kubernetes (an open-source orchestrator for deploying containerized applications) has transformed from a tiny project co-founded by three people, Joe Beda, Craig McLuckie, and Brendan Burns, into a production-grade infrastructure that powers large-scale production applications in various fields, from machine learning to online services.
Created with the intent to simplify the task of building, deploying, and maintaining distributed systems, it allows people the world over to achieve new levels of velocity, agility, and reliability. Over the years, Kubernetes has grown into a large, successful open-source community - but it was a long journey getting there.
What is a container?
Before jumping into the history of Kubernetes, let’s first define a “container” because it often has a broad set of meanings.
Fundamentally, a container is the process of taking an application and packaging it, building a binary representation of the pieces that make up that application like the software, configuration files, etc., and having a protocol for distributing it around the world.
There are three pillars of what became known as containers:
Packaging everything so it's exactly the same, for instance, on a laptop as it is out in the cloud
The distribution of step 1 needs to occur easily and around the world
Creating an environment where a bug in one component of the process doesn’t affect another component
How it started
When we interviewed Kubernetes co-founder Brendan Burns on the Dev Interrupted podcast, he told us that as an engineer, he found himself gravitating towards spaces with opportunity. While working at Google, he noticed that Cloud had a lot of white space and thought it would be an attractive space to work in. At the time, he led a small team of about seven engineers and decided to transition his team over to Cloud.
At the same time, his eventual Kubernetes co-founders Joe and Craig created Compute Engine, the virtual machine product for Google Cloud, and the three of them began to work together in Google’s Cloud division. While Joe and Craig focused on compute, Brendan worked in config management on things like CloudFormation and Terraform.
Ideas were starting to coalesce, and the three of them were witnessing the challenges people faced trying to adopt Cloud - a far too difficult process. There were also some internal systems at Google, in particular a system called Borg, a cluster manager that’s still used today, that served as the initial inspiration for the three developers as they dreamt up Kubernetes.
However, none of it would have been a reality without Docker.
Docker changes everything
As a prerequisite to the functionality of Kubernetes, people needed to be motivated to build container images and run containers. Docker was the startup that came along and convinced people why they should care about containment. All of a sudden, a use case existed, and an amazing opportunity presented itself.
Docker didn’t have a lot of experience at scale, and they were focused on one machine, with a container and daemon on that machine - what they were lacking was orchestration. If a system was built that could act as a container-orchestrator, it represented not only a massive opportunity to change the market but to change the entire cloud landscape.
When you think about what it takes to deploy an application up to the cloud or even to an on-premise collection of machines, it’s a lengthy process. It requires you to package up an application, distribute it, keep it running, have load-balanced traffic between the various pieces of the application, and an API to tie it all together.
Prior to Kubernetes, some of these systems were in place, but nothing like today. Kubernetes is responsible for mainstreaming the idea of a distributed systems application environment for building and constructing distributed systems that span machines far and wide.
With the need for orchestration realized, the next step was selling the idea to executives.
Selling open source
Convincing people that it was possible and a good idea was pretty straightforward. There were folks at Google who understood what Joe, Craig, and Brendan were trying to do. The real battle was fighting to make Kubernetes open source. As Brendan shared in our interview, they had a lot of internal arguments at Google about it being open source.
Mostly it came down to money and control. From a business perspective, if a product or system is massively successful and you’re the only one who can sell it, then you’re in a great position. Conversely, Brendan told us that he always felt that Kubernetes would only be massively successful if it had an ecosystem, and the best way to foster an ecosystem was to make it open source.
This viewpoint is centered around the community that comes together to build the software. An amazing community formed early on of people who helped build docs, who helped build tutorials, who would talk about their work at conferences, and then an ecosystem of companies that were betting their whole business on the success of Kubernetes. Startups began popping up, saying things like, “Well the prerequisite for using my monitoring software is that you have a Kubernetes cluster.” All of the attention and goodwill formed a sort of virtuous cycle around Kubernetes.
It can be easy to look back and assume that it was easy, because Kubernetes just took over. It's present in every major public cloud at this point, people expect it to be in new systems. But the truth is that in those early years, it took a lot of hard work to build and evangelize Kubernetes.
Brendan shared with us that his hope for the future is that the bits of Kubernetes sort of fade into the background. It’ll be there, and it’ll be important, but it won’t be talked about or thought about from day to day because, as he puts it, “There’s so much more that needs to be built.”
Thanks for reading! If you want to stay up-to-date with what top engineering leaders are thinking about, subscribe to the Dev Interrupted Substack.
You'll get access to weekly articles, podcasts, and news from the best engineering leaders in the industry. Enter your email below to subscribe and be a part of our growing community!
In my role as an engineering manager, I know making the leap from an individual contributor (IC) to engineering manager (EM) is not a promotion. Instead, it’s a different career track. What we are discussing here is a fundamental difference in terms of the responsibilities of the roles. What you do as an engineering manager versus what you do as a developer is fundamentally different. There is a possibility that you might not write code altogether. A promotion means continuing to do the same thing, while being paid more to do it. Becoming an engineering manager means transitioning to a different role with different responsibilities. In other words, a separate career track.
First, let’s break down our target audience into two groups. One group who is transitioning into engineering management. And then, the second, folks who have been made engineering managers recently. For those who are still considering, this decision could be made due to a couple of factors. It could be tenure-based, it happens in many companies where you are the senior-most engineer, or you have spent a fixed amount of time. The company or the team believes that you're ready for managerial responsibilities, asking you to make the switch. This is a more traditional track that we see. Alternatively, there's a more interest-based approach that you could be even at a mid to senior software engineer level.
An important clarification with this is when to use the term "tech lead" and "engineering manager" interchangeably. The Tech Lead is a system owner, and the Engineering Manager is more of a team/people manager equally. So the former is responsible for the overall success of the architecture while the latter is responsible for the team success, motivation and morale of the people they manage.
There are some key signals regarding both the tracks (IC & EM) to be aware about. They are:
1. Amount of coding time
Are you able to compromise on the technical output that you will end up with as an engineering manager versus a strong engineering IC? If you are coding 60 to 70% of your time currently, let's say it's going to reduce to 0 to 30% of the time. Yes! ZERO is a reality in this case. I have spent months where I'm literally not doing any coding in my role. There are EMs out there who would say they are able to still do coding and remain technical in terms of writing code day in, day out with an EM role. But, honestly, I don't believe that is a scalable practice.
If you are still taking on critical hands-on development tasks as an engineering manager, you run the risk of becoming a bottleneck for your team. For instance, if you are not available during the week, you need to do a lot of performance reviews or you are in some strategy meeting.
2. Focus time vs meeting time
Are you okay with spending 50-75% of your time in meetings and tackling action items? If a company is in a hiring mode or if there is a performance review season, or if there is just any ad hoc conflict that comes up, or mentorship in your one-on-ones with direct reports, there are many meetings/commitments. This is especially true now with remote culture and distributed teams. The amount of context needed to succeed in this role is quite high.
3. Definition of success
Are you okay with the definition of success becoming vague? What I mean by that is, as an engineer and an individual contributor, there were days where my code would pass, I would complete the feature, the build was great, I would get a dopamine boost at the end of the day and I could say, "Wow, it's a productive day!" Basically, I could see clear output as an engineer when I completed a task, or my work was released.
As an engineering manager, it's difficult to define what success looks like for you personally, because there are no metrics which tie to individual engineering management. For an engineer, it is lines of code or the amount of work you completed, features you pushed, zero bugs introduced. All those things are great success indicators for a strong engineer.
For an engineering manager, you must find your own metric set of what success is, which is ‘maybe there was no conflict in the team this week’, ‘maybe there was no deadline that was missed this week’, ‘maybe there is no question in terms of the meeting’ that I had with the stakeholders, and everybody clearly understood the requirements that were there for that week. Overall, it becomes abstract, and you need to self-identify what success looks like.
Sponsored Section
Want a better understanding of your success as an engineering manager? Need to understand how your team is performing? LinearB automates your teams metrics program so you can drive continuous team improvement - and provides your developers with tools to help improve, orchestrate, and automate their work.
Are you okay with the mindset of being an enabler versus a creator? As an engineer, an individual contributor, you have dedicated time to implement features. It’s your job to create things. However, as an engineering manager, you are responsible for enabling the creators to do their job. So, you are unblocking the team, you are giving clarity to the stakeholders, you are giving clarity to the team, you are providing updates to the leadership, you are sharing updates with other teams. Thus, you are enabling a lot of information sharing and removing bottlenecks for your teams and team members.
For me, it's clear that the engineering management and leadership track is a parallel career ladder on a separate track. It is a lateral move in that sense. It's not a vertical move and it's important to know the difference. The good part? In my experience, it is worth attempting to become an engineering manager because if it doesn’t suit you, you can always go back to being an individual contributor.
Join the Dev Interrupted Community
With over 2500 members, the Dev Interrupted Discord Community is the best place for Engineering Leaders to engage in daily conversation. No sales people allowed. Join the community >>
Everyone has their own definition of true leadership. What I didn't understand at the start of my leadership journey was that each of us is a leader. Regardless of intent, we influence and impact our communities, industries, workplaces, and relationships. Yet, often we don't understand the importance or impact of simply being present. So I wanted to write a message to anyone looking to grow into engineering leadership. This was the letter the younger version of myself needed and I hope that it will highlight the importance of self-empowerment in your journey.
To Whom it may concern,
Anyone remember by history has taken it upon themselves to venture down their own path. In some instances, these individuals stood their ground and continued forward in the face of violence, war, political and economic systems, beliefs, and stereotypes never before challenged. And so they changed the perspectives and consequently the lives of individuals around them. These individuals didn't stand out by being just like everyone else. Instead, they took up the metaphorical shovel and paved their path by taking actions in alignment with what they believed and desired.
Impact is Power
I want to bring attention to the notion of impact. These leaders influenced others to pursue their own paths even when they weren't speaking. By simply showing up in their spaces and picking up the shovel, they allowed others to do the same. These leaders understood what others would have to do to take up their own shovel and make way for their path. This is progression. This is the beginning of leadership. This is power.
No leader does anyone in their community good - whether leading an engineering team, organizing a non-profit, or elsewhere - by hating themselves, fearing their strengths, and refusing to take action where necessary.
Empowerment is the currency for operating with a sense of agency. There are at least two things you need to empower others: the first is power, and the second is integration. Power comes from authority and authorization and we can have internal and external centers of focus. Understanding how power and agency work allows for integration, and we can only begin to empower others when we include, communicate, invite, and co-create.
Leaders maximize their potential for impact. As an engineering leader, you get to facilitate and help lead the team to success.
The Emotions of a Leader
Let all that I've shared sink in. Just by being where you are today, you have proved that anyone else can do it. There's no escaping the power of impactful leadership. So let's share how our emotions and energies inevitably amplify the potential for success.
Leadership communities tend to focus on developing characteristics such as compassion or empathy in leadership, yet these traits alone don't make a leader in a workplace. Sometimes, these traits can cause us to take actions that neglect our boundaries, goals, and purpose. Therefore, we should consider how these traits can help us process our emotions and invest our energy properly into needed action. Leadership traits are like water. They allow us to flow and direct our energy. These traits don't substitute for the core strength of a leader.
When we can understand the impact and effect of authentic leadership, we can feel pleasure, motivation, pride, and joy for the work we do in the world. Leadership gets to be and feel good.
There are no shortcuts to realizing what leadership will mean to a leader because it's everything: joy, sacrifice, compassion, celebration, risk, gratitude, accountability, perspective, setbacks, success, etc. It's more than who we are as an individual, and it gets to be whatever you want it to be.
Empathy and compassion allow us to make our leadership feel good for others as well. For example, engineering managers that understand why it feels good for engineers on a team to deliver well-understood and maintained code on time, and make space to introduce specific practices that ensure these conditions are met.
The Core of it all, asking the hard questions
Every leader needs a purpose. How do we want to show up in the world? What do we want to create? What impact do we want to leave behind? These questions are important because how can you expect impact, integration, and success if you don't get them right? We'll all face setbacks, mistakes, conflict, and confusion. The core foundation of leadership is purpose. We mentioned self-empowerment earlier, but power is also derived from purpose.
It's similar to building a snowball. First, we have to pack the core tightly before adding additional layers of snow. Else we risk crumbling. And like snow, our goals and purpose can change.
I encourage aspiring leaders to consider what it means to be an individual contributor, a leader, an engineer, a project manager, a product manager, and anyone else on your team. Then, ask the hard questions and start to forge an answer, even if it's not the right one the first time around.
In closing
Leadership doesn’t happen overnight. Making it a reality means taking up a shovel and doing the hard work. It means continually empowering yourself, connecting and investing in others, and asking hard questions. Our software code is always in the pursuit of being understood, loved and in service to others. As an individual in an engineering manager or leadership capacity, we influence to make this a reality for our teams, communities, and industry—best of luck to those seeking true leadership.
This letter shared some insights into power, connection, and purpose as a leader. I hope it was useful to anyone looking for some encouragement related to being a leader in their capacity. Please feel free to connect with me if you enjoyed this piece or have any questions.
Join the Dev Interrupted Community
With over 2500 members, the Dev Interrupted Discord Community is the best place for Engineering Leaders to engage in daily conversation. No sales people allowed. Join the community >>
A year ago I wrote an article for Dzone titled The Rise and Fall of a Senior Developer. Filled with personal anecdotes and stories from my years as a software engineer, the article was a critique of industry practices surrounding the somewhat controversial issue of ranking programmers’ seniority. I realized that I might sound like an elitist dinosaur patronizing the upcoming generation of software engineers. A sort of “back in my day we did things differently” mentality that every generation seems to age into.
So you can imagine my surprise when the article became not only my most popular submission, but caught the eye of Dan Lines, host of the Dev Interrupted podcast.
In a follow-up to my article from last year, I’d like to share some of the takeaways from my discussion with Dan and discuss whether or not some of these hiring practices have changed in the past year.
The rise of remote work is truly changing the landscape of hiring developers and finding talent. But are companies better able to find The True Senior Software Developers in 2021?
What is a "senior" developer?
There is no objective measure of a senior developer. Everything is dependent upon the specific work environment a developer finds themselves in. A humorous analogy could be the movie Idiocracy. Seniority is determined very differently in an environment where your superiors have less knowledge and experience than yourself. Likewise, in a highly technical environment filled with experienced individuals, for instance, Tesla’s autonomous car team, you might discover seniority is determined by different standards.
My most pragmatic answer is to say that it really depends on where you are and that hopefully your organization isn’t being run completely incompetently.
To me a senior is someone who has mastered their domain beyond a majority of their team. That's probably the safest way for a manager to define how to find a senior developer: quantify the average level of knowledge on their team, and seek somebody who is above that average.
Being good at your job doesn’t make you senior
Not everyone hired at a company can be a senior developer but that’s a good thing because you don't want everybody to be at the high end of the spectrum. You need a team which is properly varied and has people with all levels of skills to fill in all the niches and gaps in your development process.
Very often, companies just need someone who is good at React or proficient in TypeScript, able to adapt well to a team, understand a project, pick up tasks and implement them efficiently. That’s a good developer - not a senior developer. Those are things that you would expect from any member of a team because that’s what you pay people for.
I believe that when you're looking for a senior developer, you should be evaluating well above average. Unfortunately, it seems many companies advertise for senior developers, in the hope that they will somehow filter out the noise and get the most talented people, simply because they made it clear they were searching for senior candidates.
Of course every developer that shows up to an interview is going to say “I am a senior developer, a god amongst men.” Why? Because that’s what everyone wants to hear!
That's probably a reason why seemingly 90% of advertisements for developer positions are for seniors, while the reality is that on a team there are only a few seniors.
Experience isn’t everything
Though a year has gone - and you, dear reader, find yourself with another year of experience - that’s not an indication that you have magically become a senior developer. My belief that experience matters but is in no way an indicator of being a senior developer hasn’t changed.
Let's be honest, somebody can be a lazy bum for ten years and by sheer luck navigate through corporate realities and get away with it. As I said before:
“10 years of JavaScript is just as good of an indicator of me being a senior programmer as 10 years jail time for armed robbery is an indicator of me being a law professor.”
Years of experience are needed, but I would never use them as the sole indicator of being a senior.
Where are we today?
Now that we have recapped, where are we today?
The rise in remote work is changing the hiring landscape and the development process. Companies are beginning to shift more teams to asynchronous development or hybrid models. These changes might be well-received by individuals but what will the long term impact be on hiring practices?
It’s my opinion that companies are way too focused on the hottest frameworks, coolest tricks and fancy techniques, while forgetting the bigger picture, the concepts and principles behind software engineering and languages.
In the interview process applicants will claim to be Angular senior developers because they have an understanding of how to set up Vuex state store or fetch data from REST service using Axios, but having no idea about observer pattern, how asynchronous JavaScript actually works and are ignorant about prototype inheritance.
All these fancy things, they come and go very fast. But fundamental knowledge stays with us much longer, and if needed, allows us to learn all these transient frameworks, fads and fashions.
Companies need to train themselves to filter out the noise. Don’t hire for passing fads. Look to hire developers with strong fundamentals because those are difficult to teach. If a candidate is good at something, even if it’s not the particular framework or language you are looking for, you should not dismiss them.
A real-life example
When I arrived in Ireland, I began applying for jobs and got interviewed by two gentlemen who started grilling me at the whiteboard. At some point during the interview I interrupted and said, “Guys, I think you have the wrong person here. I came to Ireland with a background as a .NET with a specialty in C sharp.” They wanted someone proficient in Python and I had never worked with it professionally.
What they said next completely blew me away:
“We understand you don’t know much Python but we like your way of thinking, we see you are a brilliant C sharp programmer.”
Then they allowed me to take the test assignment for the interview in my preferred language of C sharp. Once I finished, they brought in a colleague from another floor who was a C sharp expert, he looked at my work, gave his approval, and they hired me on the spot.
After about half a year, I was actually teaching Python to junior developers on the team.
I was taken by this honest approach to logic and hiring. They recognized an expertise in me even if it wasn’t exactly what they were looking for.
There’s no replacing good fundamentals
It’s possible that the past year, and the continued evolution it has brought to remote work and remote dev teams, has caused more companies to jump at the chance to hire senior developers who claim they are experienced just because they put “managed remote dev teams for x years” on their resume.
But when I watch events like this remote engineering panel, it is my hope that more people in the industry are adequately identifying The True Senior Software Developers, by avoiding the pitfalls of buzzwords and fad languages to hire exceptional individuals.
While the fads and fashions of 2021 won’t be around forever, good fundamentals aren’t going anywhere (remote work might not be either.) Stick to hiring principles with an emphasis on expertise, but avoid having so narrow a view as to overlook talented individuals, and remember to always give honest feedback.
Not everyone is a senior developer, but if we’re honest with ourselves and our abilities, we can all take the steps to get there!
If you’re interested in this topic, you can find more content like this on my blog at https://letsdebug.it.
Also consider checking out Dev Interrupted, a weekly podcast featuring a wide array of software engineering leaders and experts, exploring topics from dev team metrics to accelerating delivery.
Join the Dev Interrupted Community
With over 2500 members, the Dev Interrupted Discord Community is the best place for Engineering Leaders to engage in daily conversation. No sales people allowed. Join the community >>
I try not to get involved in arguments - but when a debate started in the Dev Interrupted Discord about if exceptional continuous improvement (CI) or continuous delivery CD) makes a group agile or not, I had to jump in. I’ve helped build many high-performing teams with agility, and I know that neither CI/CD nor Scrum makes an organization Agile.
It’s Not What You Do, It’s How You Respond
Probably my favorite way I’ve ever heard someone describe agility was that it’s about moving away from believing we can predict and plan everything to sensing reality and responding to it instead.
Consider two extremes. In the “predict and plan” view of the world, we build a feature list, come up with screens, represent that in a backlog, and dutifully execute in two-week chunks. This approach focuses on accurate plans and predictions in the early stages. Mistakes in the early stage compound rapidly later on.
Are these folks agile? What did they sense and respond to?
A different group has a sense of problems to solve and their relative importance to one another. This group decides the goal for their next investment in a sprint. Every day they look at what happened and determine if they need to change course. They frequently shift direction mid-sprint because they’ve learned something new. Are they agile? What are they sensing and responding to?
Both teams are following Scrum’s rules, but one has lost all its ability to respond to new information, and the other, while it seems chaotic, is using near real-time data to guide their next steps.
Regardless of how you do it, agility is a lot more like the second group than the first. You can tell this not by the meetings they have or titles like Scrum Master, but rather by the frequency with which they make decisions that significantly change their direction.
You Have To Have Working Feedback Loops
A way to detect weakness in a group’s pursuit of agility is to examine the strength and length of their feedback loops.
Scrum is a framework, which is a weird way of expressing that it has a few useful pieces and room to figure feedback loops for yourself. The parts it does have, though, are a series of events and structures that provide feedback loops.
A feedback loop is an activity where you can pause to look at the results at the end. A chef that tastes their own food as they prepare it creates a feedback loop. A chef that never tastes their own food or waits until the dish is finished to take a taste, does not.
If you think about the events of Scrum in terms of feedback loops, every activity has a counterpart that closes the feedback loop. Sprints have Retrospectives, Increments have Reviews, and each day has a Daily Scrum.
All too often a Sprint Review is nothing more than a team saying they did a bunch of stuff with no actual feedback happening. The same can be said of Retrospectives, where the team produces many stickies, but no change manifests. The Daily Scrum Is a daily feedback mechanism, but all too often reduced to merely a task status update.
Scrum puts the potential to leverage these feedback loops in place, but they don’t work by themselves. So you can easily wind up with a team building a two year roadmap, executing on that roadmap, but never recognizing the signals that there is actually no market for what is being built.
Sponsored Section
One way to ensure quick feedback loops internally? Cutting the review time for code in your development process. WorkerB developer automation tools by LinearB can give your team proactive notifications of changes in their PRs and update developers on long PR review times while correlating the PR to the relevant project issue.
I often see groups espousing that they are agile because of some activity they do or capability they have. In fact, that very behavior is what inspired me to write this article.
It can be tempting to look at agility as a feature list or series of checkboxes that, if you complete enough, you’ll summit the mythical agile mountain. But if those things aren’t so important, are the rules important at all?
Well, they are, but it’s just not enough.
Organizations and teams put a lot of emphasis on getting the basic structure of Scrum in place but tend to get into the rut of standing pat with those structures, and so the promise of agility remains elusive. These groups similarly work hard to cut things that they’ve been told are not agile anymore. Basically, they focus too much on the form, and not enough on the function.
You have my permission and support to keep using work-breakdown schedules as you pursue agility.
On the one hand, you need the form to be correct, or you can’t get the benefit. On the other, if you only follow the form, you stand in place.
So with my teams, I look to see if our process is “alive.” With a clear purpose for each activity, I can quickly see which of them are exhibiting signs of weakness that will disrupt feedback. Then I can intervene and bring the form back to accomplish its purpose.
For example, in a talk I give about Daily Scrums, I say, “The purpose of the daily scrum is to begin the day’s collaboration and coordination towards a sprint goal.” Most daily scrum meetings miss the mark of that purpose.
Looking at things from this angle, we can mature our forms and get the benefit back.
Change Takes Time
There is a fascinating intersection between these concepts where we recognize we want to address weaknesses in how we practice agility, but have difficulty estimating how to move forward and how long these changes will take.
One aspect to this is that we do need those forms to be in place before we can sense and respond to it. In my experience, a change in these forms takes about three months to normalize in a group.
When I introduce more advanced concepts like Test-Driven Development or Work-in-Progress Limits, I introduce those forms and also hold them in place for three months. This time frame might feel slow, but it comes down to how we as people handle change.
What we’ve done in our past is what frames what makes sense to us today. Our brains crave that feeling that the world works a specific way. When we disrupt that, people’s instincts are to reject the change. Even if it is a rational and logical change, we’ve disrupted what is normal. The three month adjustment period seems to be enough to allow change to take hold and for a new normal to be realized.
During that whole time, though, the form has to be sustained.
So as much as adherence to form can be a trap, it also is the scaffolding for change.
Learn to be Comfortable with Change
My honest advice for leaders who want to make things a bit better is to get really comfortable with microscopic change for a while.
An example might be phrasing a question differently -- a small change.
Take an honest look at how you view things working best along a spectrum of plan and predict and sense and respond. Make sure to compare how you think you do to the actions that actually take place. There is usually a disconnect there.
Next, look at an opportunity within the existing forms to strengthen a feedback loop. Using something as simple as phrasing a question differently -- a small thing -- can completely alter the course of a Review or Retrospective or Daily Scrum. A thoughtful question that encourages feedback can easily improve things..
From here, you can continue this pattern of making small adjustments to how you and others move towards sensing and responding and leveraging the forms of Scrum to become truly agile.
Join the Dev Interrupted Community
With over 2500 members, the Dev Interrupted Discord Community is the best place for Engineering Leaders to engage in daily conversation. No sales people allowed. Join the community >>
Unless you’ve been living under a rock for the last year, you must have heard about this brand new shiny thing called “No-Code” and “Low-Code”. According to Gartner, 50% of all software projects will be delivered before the end of 2021 using Low-Code and No-Code constructs. Even if Gartner’s numbers are inflated, automation processes for generating code automagically have gained traction lately, and it has gained traction very, very, very fast. So obviously we’re way beyond the “hype factor” in regards to these technologies. Hence, in this article, I will try to break down the advantages, and illustrate with an example use case, so you can see the advantage for yourself. But first I need to define Low-Code and No-Code.
The difference between Low-Code and No-Code
Although obviously related, Low-Code and No-Code are actually two completely different concepts. No-Code is the idea of “citizen development”, where people without software development skills can create software. This is typically achieved through drag and drop interfaces, similar to how DreamWeaver worked a couple of decades ago. On the other hand, Low-Code is typically a software system that generates code automagically for you, by for instance reading metadata from your RDBMS, or Swagger, etc.
In a way, you could argue there’s nothing new to No-Code. DreamWeaver has had No-Code constructs since the late 90s, and so have Adobe Flash, Microsoft, and literally every single software company out there beyond some certain size threshold. Visual Basic and WinForms for instance used to have GUI interfaces for “generating code by dragging and dropping components into a visual surface.” While Low-Code it could be argued, has always been around in some ways, due to individual software developers’ ability to reuse Open Source libraries and frameworks, to reduce the workload required to deliver applications.
So what’s new?
Well, let me illustrate with a walk down history lane, and use Gutenberg and the printing press as an analogy for what’s happening. In the 15th century, it would require one human being roughly 18 months to copy a Bible by hand. These jobs were typically done by monks, and because of the resources required to create a Bible, “the Good Book” typically took 300 sheepskins or more to create. One hundred years later, Gutenberg’s printing press became mainstream, and today born again Christians are throwing Bibles at you on the street for free. With mass printing, the cost associated with creating books has plummeted.
This was only possible because of the printing press, and its ability to automate what was previously a manual job. Hence, the more we can automate, the lower our total cost of ownership(TCO) becomes. Such benefits don't require a Ph.D. in math to understand but are probably intuitively understood by most.
With today’s automation techniques based upon Low-Code constructs, we’re now at the point where we can deliver similar optimizations in regards to “generating” software systems that result in the same quantitative improvement of the TCO of creating software. To illustrate it as blatantly as I possibly can, let me ask you a question: “Would you want to pay 50 million dollars for your software, or would you want to pay 50 bucks for the same thing?” This is really the heart of the matter. To understand how this occurs, imagine having to create your own operating system to serve your own software. Obviously, such a thing would be madness, when you could just pick Linux off the shelf, and start out with an Open Source system solving these problems out of the box. Hence, the qualitative similarity between Open Source and Low-Code.
A Low-Code use case
Disclaimer; I’m the CEO of ServerGardens.Com, and we exclusively deliver software systems based upon Low-Code constructs, and our own internally created Open Source system we refer to as Magic Cloud. Therefore, I might not be completely without bias. But really, most people can easily reproduce what I’m about to show you here, so it doesn’t really matter if I’m biased or not, since you can test and verify my thesis yourself. Anyways, with that out of the way, let’s illustrate a use case for Low-Code.
One of our clients came to us and asked us to create a CRM system. It needed the ability to track purchasing and selling of horses, and hence a traditional CRM system couldn’t be used, since it was more like a logistic system that he needed than a traditional CRM system. We spent 25 minutes creating a database schema after having asked some questions about how he wanted it to look, and digging through Google Spreadsheet documents which he was currently using for this job. All in all, the process took about 2 to 3 hours before we had a working system deployed into production for the client.
The process was as follows: After we had the database done, we clicked one button, and the computer-generated 1,813 lines of backend code for us; this code again became the input for the next button click, which generated 27,000 lines of frontend code. Even after having removed the boilerplate code you’d typically have around in a manual workshop, we’re easily looking at 10,000 to 15,000 lines of code here, automatically generated for us, in 2 seconds. And the code is perfectly valid Angular code in the frontend, and Hyperlambda and .Net 5 in the backend.
And of course, the code generated by our system is easily several orders of magnitude higher quality, according to every single neutral metric we use to measure quality. In fact, run this code through one of your frontend/Angular developers if you want to assess it from a quality perspective. I guarantee you that he won’t find a single bug in it! Then realize that this code is running here. Try it out for yourself by logging in with admin/admin.
The reasons for the qualitative improvement are quite simple to understand, In fact, our stuff runs in thousands of apps, implying we can share the burden of improving it equally with many projects. Something you’d typically never be able to afford if you manually write code on a per-project basis. To see this effect in the printing press improvements, try reading an old Bible that was manually written by a monk 550 years ago (if you can even find one) - then try to read one of Gutenberg’s Bibles and notice the difference in readability. Low-Code improves both your quality and reduces your cost by several orders of magnitudes.
How Low-Code improves quality and reduces cost
The way it works is by reading metadata from the database schema, to then use this metadata as a “formal specification” to generate the backend. The backend exposes a lot of metadata itself, which again is used as a “formal specification” to generate the frontend. However, the time to market quantitative improvements is simply ridiculous. To understand why realize that a (human) software developer can deliver at most 750 lines of code per month. Our software system delivered at least 10,000 lines of code in 2 seconds. Of course, these types of comparisons aren’t completely fair one might argue, but this becomes a quantitative improvement of 17,280,000 times faster Time2Market! In fact, so far I have not been able to identify a theoretical upper limit in regards to either quality or quantitative improvements. In theory, our software systems can produce 750,000 lines of code per second, which becomes a quantitative improvement of 216,000,000 times faster than a human being.
Hence, we’re now at the point where we can literally throw customized software systems at our clients - almost the same way born-again Christians are throwing Bibles at strangers on the street - simply because of the cost associated with creating such custom software systems for our clients is almost ZERO.
BUT…?
Yes, there is a “but”. For instance, our system needs an existing database. The end application will also be database-centric, implying it’s typically for the most part only interesting for CRUD systems, where CRUD implies Create, Read, Update and Delete. However, the last figures I saw in regards to this was that there are 26 million software developers in the world. These numbers are a bit old, and are probably much larger today than a decade ago when I saw these figures. Regardless, the ratio is probably still the same, and the ratio tells us that 80% of these software developers work as “enterprise software developers.” An enterprise software developer is a developer working for a non-software company, where software is a secondary function.
Examples could be insurance companies, banks, hospitals, or the public sector. So let’s imagine there are 21 million enterprise software developers in the world today and 80% of their workload is CRUD. If you don’t believe me, go ask your DBA how many relational databases you have in your company, and whether or not these are crucial for your company to function. Chances are his answer will be, “Our company would go bankrupt if we lost these database systems.” Then realize that every single time your applications are accessing these database systems, they are either Creating, Reading, Updating, or Deleting items from the database - A.K.A. CRUD!
This implies that if you adopt Low-Code and Open Source as a strategy for your enterprise, you can optimize the way your software developers work by (at least) 5x, probably much more. Simply because at least 80% of the work they need to do manually is as simple as clicking a button, and waiting for one second for the automation process to deliver its result.
Also realize that the code generated is just plain old fashion code, that can be easily extended upon by your (human) developers once the process of automatically generating the automated parts is done. Except, of course, your (human) developers start out with something that is 1 million times higher quality than whatever they would typically be able to start out with themselves. Respectfully, but there is no way of saying this politely, so I’ll just say it: Not taking advantage of such improvements is simply madness!
Wrapping up
If you want to play around with the Open Source Low-Code framework that delivered the above results, you can download it for free from our website. All of our tools and Low-Code constructs are 100% Open Source. We also help others strategically make the transition into a Low-Code automated software development ecosystem if they need help. Our services include training of your existing software developers, open-source frameworks, hosting, and, of course, software development at the speed of light! See you at the other side of the Universe mate ^_^
Join the Dev Interrupted Community
With over 2500 members, the Dev Interrupted Discord Community is the best place for Engineering Leaders to engage in daily conversation. No sales people allowed. Join the community >>
In the past year-and-a-half, going remote has been the primary goal and focus for many companies and individuals. The beginning of the remote work overhaul was rocky to say the least but now that all this time has passed and workplaces have figured out how to work with it and not make it an utter mess- Is it worth keeping? Is it better than being in-office? Should remote work be a standard for dev teams, and in-office be secondary?
Well, that depends on a couple of factors. With some feedback from the Dev Interrupted Discord community, let’s dive into the advantages and disadvantages of remote work.
The Disadvantages
Team bonding is difficult
“It's not impossible or anything, but I've found it's so unbelievably easy to bond with a team in person doing regular lunches and such. (...) I miss being able to see someone frustrated or struggling with something and walking over to them with a couple other people and saying "let's head to lunch and clear our heads." You build bonds very quickly when you do demonstrable human things to reduce someone's stress.” - Discord User The Panda#2143
Jumping off from what The Panda said, the first major disadvantage that many people will voice is a lack of genuine team bonding when your team is fully remote. It requires much more active effort to bond with your teammates over Zoom. Being around another person naturally speeds up the bonding process much more than occasionally messaging someone because you need something.
When working remote, your team needs to be intentional about team bonding. An excellent way of maintaining some form of social bonding is to have a weekly meeting where you can just sit down and chat with your colleagues, talk about what you did on the weekend, maybe occasionally host a “show and tell” of your own. Figure out what fun little trinkets your colleagues collect! Another popular weekly meeting idea are “coffee talks”, which are informal breakout rooms hosted on Zoom that can be hopped into or out of at will.
Team leaders also need to be sure to regularly schedule fun events - whether in person or online - to bond team members. This could be a happy hour where everyone gets shipped a cocktail kit and makes them together, or a digital magic show, an in-person meet up, or something else.
Video Call Dread
Sometimes, it is just the most inconvenient thing to be forced to have to sit around in a conference call several times a day to get things done. Text is confusing, unclear. But you have to discuss things somehow, so you end up calling. And calling. And calling- is it just me or is it simply exhausting to sit around with the “important work meeting” looming overhead in between everything you do? Even many industry leaders and remote work proponents discuss what they often refer to as “Zoom fatigue.” In a recent remote work panel hosted by LinearB, video call dread was highlighted as a major downside of remote work.
“My kid’s school over the last year has been trying to keep us involved, and one of the ways they’ve done that is booking these Zoom sessions in the evening. I notice when I get [to the meeting] I just don’t want to be there. I’ve been on video all day long.” - Lawrence Mandel, Director of Engineering at Shopify
One of the biggest appeals of remote work is that you have so much freedom to do things on your own time and create focus time, but it is nearly impossible to feel comfortable doing a different activity for a while when you’re still in “work mode”.
So while in reality you do focused work for 4-5 hours, mentally you’re still working the whole 8-9 hours. The meetings and work you do aren’t consecutive and are instead the equivalent of a car starting and stopping in a traffic jam. Every hour or two, you have to sit up and move .5 metres before you sit around and do something else again. It gets exhausting.
Despite everything, remote work is still built around the idea of being in an office for nearly half the day. Which really shouldn’t be a surprise, as remote work was never about changing the working hours, but the expectation often comes with it.
Lack of printer access.
Okay, Really, this isn’t the biggest disadvantage but it's something that I, as a young man under the age of thirty, found highly amusing. I can guarantee that a majority of people today just don’t own a printer. And that makes sense, you generally don’t have to print a lot these days! Though, in many cases, having an on-paper copy of a digital file is reassuring to have. (At least for me, I prefer having paper copies of important documents over a file on my desktop!) If you’re going to be working remotely, you may have to invest in a printer. Or hope there’s a copy-shop near you. You really don’t realize how convenient having a printer at work can be until you’re forced to work from home.
You’ll also likely be forced to learn the true cost of printer ink if you haven’t already. Oh dear.
The commute was a benefit!?
For many people, the commute is a huge issue. Especially if you have to drive a car, or take public transport. In cases like those, getting to work remotely and avoiding that mess is great!
“I miss my commute. It was a 10-20 minute bike ride depending on the route and the weather. I would do it year round in a winter climate, and I always was very happy about the forced fresh air in the winter. The idea of jumping on a bike in subzero snowy weather seems terrible until you're out there, so it made the fresh air and exercise happen.” - Discord User ParksideBrad#9930
To some hardy souls like ParksideBrad, the commute was actually a beneficial and nice thing. Either way, losing that two-birds-one-stone manner of exercising and getting to work can be a noticeable hit to your daily schedule. While this can be solved by just exercising on your own time- it’s harder to have to intentionally build that into your routine. It’s hard to exercise without reason ( “Getting healthier” isn’t really the best motivator for many, even if it's important.), so using “Going from point A to point B while exercising” as a manner of getting that important movement in is a very valid way of keeping yourself healthy mentally and physically.
The Advantages
No commute? Perfect! (Sorry, cyclists!)
Alright, so sure, I did just write that the commute could be a benefit for those that like to exercise. But really, for a majority of people it was always a pain. Getting an extra hour to yourself in the morning is a significant bonus as you don’t feel the need to rush yourself out of bed to avoid any traffic. And getting extra time to yourself just throughout the day? Honestly, the following words by some of our community members emphasize how much better a lack of a commute is for many people:
“With no commute and no office tying me down, it's easy to work from just about anywhere the internet exists. This facilitates living in new places, experiencing new things - which is amazing! ” - Discord user NobilityPNW#7631
"One big disadvantage of Remote Work: avoiding commute times! I do not miss commuting at all! I save a ton of time that I can use for work or for work/life balance and necessary tasks. I'm also significantly more flexible." - Discord User Conor#3700
More hours in the day are dedicated to you
Your 24 hours in the day are not the same as Beyoncé.
This is a sentence that often gets thrown around in the following way: “You have the same 24 hours in the day like [insert celebrity or billionaire here]”. Sure, you both have 24 hours to do everything in the day. But the allocation of those hours is vastly different. Because unlike Beyoncé, you can’t hire people to do your cooking, laundry, cleaning, etc, for you. You don’t get to leave all the painstakingly long chores and commutes to others.
But thanks to remote work, a lot of these things get a little less bad. Sure, you’re still working at home, but you can take breaks. You can control your activity, your time. You decide if you want to go take a brief pause to play a short game with your kids, or if you want to have a coffee with your partner. You get a chance to spend more time with your home social groups, your family, your loved ones.
“I was on a call with Dan Lines recently talking about Linear B and my 6 year old came into the room and attacked me with a nerf sword. It was short lived, not terribly disruptive, but it felt good to me knowing he had access when he needed it (I survived unscathed). For most of his life I was gone 60-80 hours a week or traveling around the country. Since we went fully remote, we are very close and he feels sad if I have to go downtown for the odd meeting once a month. It has changed our family for the better and when I feel a stronger connection to my family and like their needs are being met, I can focus all my excess energy on whatever I want.” - Discord User The Panda#2143
You finally get a printer
Congratulations! You have a reason to buy a printer. Hopefully it’ll last you for the next two decades at minimum. May the prices of ink cartridges remain low for you.
The flexibility of work-locations
Being able to work wherever at any point in your workday is an incredible advantage, especially if you struggle to stay focused being in an office environment. Having the chance to get away from the “ADHD poison” that noisy offices often are… Sitting at a quiet cafe in the park, or working from the couch at home with your beloved cat purring away, it all makes for a much better environment. And then being able to change that on a whim when you decide you’re no longer comfortable? Even better. After all, this is the easiest way for a company to support employees that may need a calmer environment to work in.
But this isn’t even just about being comfortable- it also means that if there are any issues you’re having in your home (such as construction), or your internet is down, you can still stay in touch by being able to connect anywhere else. Rather than having a whole office-outage take out several hours (or potentially, days) of work because something went wrong with the network or power.
Allowing for remote work makes you disability-friendly
This is not just for people who are disabled that apply for the job, but also for those that may become disabled during their time working in your teams. Unfortunately, life isn’t perfect, and a sudden health issue could turn out to heavily impair your wellbeing. Before remote work was standardized, if you could no longer go into work on a daily basis you would most likely end up having to quit your job. But now, maybe you can still work with your disability as long as you’re at home. Or as long as you can take frequent breaks, which are made far easier in the comfort of your own home.
The Conclusion
There’s certainly more advantages to remote work compared to the disadvantages, but this is a case where the disadvantages shouldn’t be left unaddressed.
The disadvantages often fall into real problems that have some half-solutions. But honestly? The best solution might be to reduce the amount of in-office days, and have an option and support for full remote for those that need it. Most people would be happy to go into the office for just a few days a week while staying remote for the rest. And let’s not forget that this’d be the perfect way to allow people to continue wasting printer ink at the office instead of having to invest in their own.
In the end, you must admit that giving employees agency over their hours tends to leave them happier and with a more positive outlook on their jobs.
With over 2500 members, the Dev Interrupted Discord Community is the best place for Engineering Leaders to engage in daily conversation. No sales people allowed. Join the community >>
Have you ever attended an event in which you were asked to give advice to someone starting something new (career, baby, wedding)? Whenever confronted with that question, my answer is "don't take people's advice." Not because all advice is bad, but because all people are different. I am unique, and some advice applies to me, and some not. Here are some of the items people have advised me, and why they may, or may not work.
1. “Don’t be too technical... or not technical enough.” Both? Sure… I cannot tell you how many times when functioning as a systems engineer, I was told, “You know how developers are…" Well, yeah, I coded for many years. And how often do we hear that the stereotypical engineer should not be a manager because of social awkwardness or the inability to delegate? I feel that it helps a team to have someone with hands-on experience lead them - somewhere in the middle is the best.
2. “Don’t bring treats to the office.” I can’t tell you how many articles say that if you bake cookies you’ll never reach “the corner office.” Why not? I guess baking gives the impression of being a submissive woman. People play golf, collect baseball cards, even brew beer. It is a hobby. And I love to bake. I made the most amazing ginger molasses cookies for a birthday last year. (Recipe at the end of the article!) It is also a stress reduction technique for me. In a former job, we did a management simulation for a class. We found that one way to keep morale up was to feed your team. Overtime? Get pizzas! Celebrate birthdays and accomplishments! We did really well in that exercise (until we were confronted by a debilitating snowstorm). But if I’d listened to the bad advice of many people - I wouldn’t bring treats to the office!
3. “Be assertive.” It is important to be assertive. And I am much more so than I was coming out of college. And maybe if I were better at saying no, I would not be writing this article… However, as the adage goes, “you catch more flies with honey than you do with vinegar.” On another note, there is something to be said for allyships, or the “good cop/bad cop” method. If I can keep the team happy and engaged, and someone else in the management chain or my tech lead may sometimes need to help me get a point across, would that be a bad idea? It shows teamwork and trust. Don’t over-index on assertiveness at the expense of collaboration and learning.
4. “Shoot for the corner office.” I have no desire to be in that space, figuratively or literally! I sit with my team and don’t mind interruptions (OK, maybe I need a “usually” on the interruptions). The past few assignments, I have been lucky enough to have the “Wal-Mart Greeter” desk, so I can be aware when people come by with issues, and I can experience the team banter. The idea of aiming at a corner office as a goal alienates you from team members.
5. “Working part-time hurts your career.” I worked part-time for almost twenty years, and was home after every school day to make sure my daughters were fed, taken care of, and got their homework done. How did that affect my career? Well, I got fewer raises and fell behind my full-time colleagues. But I learned to multitask, I learned time management, and I ended up with two amazing strong daughters who followed in my footsteps to become engineers themselves. You get to decide what’s important for you - and working long hours is not always the right thing for many people.
6. “Don’t have interests outside of work.” I am a big hockey fan, I read, I take nature walks and photos. I love live music, my favorite being metal. Again, how many stories do I have of people who think of me as a mellow music person (is it the cookies?) But, think about this, if you had a stressful day of work, and you are headed home in your car with the radio on, would it be more satisfying to hear, “You Don’t Bring me Flowers” or “I Sleep with One Eye Open?” You can guess my answer! Focusing solely on work will not only detract from your ability to connect with colleagues, it’ll create a life that you won’t fully enjoy.
7. “Look like a manager.” I will put it out there; not only am I female, but I am old, I am overweight, and I have blue hair. This is probably where I could go on a diversity rant. I’ll just say that the more uniform your team is, the more likely you’re missing out on some important outside-the-box ideas and perspectives. It’s far more important to be good at what you do and a strong team leader than to look the part.
So next time you give or take advice, or assume you know the job of someone you see in the office or the grocery store, think about what makes us, us; not what about us makes us who we or others think we should be. Appearances aren’t everything - and listening to the wrong advice can be worse than not taking advice at all. . . .
In a large bowl, beat brown sugar and butter until blended. Beat in egg and molasses. Combine the flour, ginger, baking soda, cinnamon and cloves; gradually add to brown sugar mixture and mix well (dough will be stiff). Cover and refrigerate for at least 2 hours.
Preheat oven to 350°. Shape dough into 1-in. balls. Roll in sugar. Place 2 in. apart on greased baking sheets.
Bake until set, 9-11 minutes. Cool for 1 minute before removing from pans to wire racks.
This article was written exclusively for Dev Interrupted.com by Judy Johnson, an active member of the Dev Interrupted Discord community.
Join the Dev Interrupted Community
With over 2500 members, the Dev Interrupted Discord Community is the best place for Engineering Leaders to engage in daily conversation. No sales people allowed. Join the community >>
Informing someone that you want to “measure” them is not a great way to start a conversation. Software developers, like all people, tend to look unfavorably upon having their performance closely measured. But measuring developers is one of the hottest trends for companies around the globe. So is it tyranny to measure people?
People are quick to note that numbers don’t tell the whole story and can become defensive at the notion their productivity should be quantified somehow. This resistance can become even more entrenched when teams become stacked against each other.
Many leaders - like Netflix's Kathryn Koehler - believe we should absolutely avoid stack ranking of individuals and teams. After all, the human elements of teams - communication, coordination, leadership - can all affect the speed or perceived productivity of a team or process, so how can you quantify that?
Thankfully, plenty of tools exist to enable a data-driven approach to the development process. With the right approach, these tools can be used to enhance any individual’s or team's performance. Beyond performance, when applied correctly, these tools can bring about more harmonious alignment between leadership and employees.
But first, why do we measure?
Why measure at all?
It’s important to remember that measuring is just a tool -- it can be used for both good and for evil. An effective leadership team understands this basic fact. The cool thing about metrics is that they provide insight that might otherwise be difficult to obtain. Employees should note that good leadership will use metrics merely to inform their decisions, not solely drive them.
As a basic rule, it is difficult to improve something that is not measured.
I started with the really basic observation that I believe you cannot be sure that you're improving something if you don't measure it, right? I mean, think of trying to lose weight without weighing yourself. -Luca Rossi, from the Dev Interrupted Podcast at 4:31
Measuring creates a foundation—a benchmark—which can be built upon. Once this foundation is established, organizations can begin to set goals. If you can set goals, you can rally a team; and if you can rally a team, you can achieve your product goals. This all becomes easier when you adopt a quantitative approach to your process. Success flows from the foundational element that measuring provides.
Lastly, there exists a psychological benefit to measuring: namely, that people implicitly understand that metrics which are measured are important. After all, no one measures something they don’t care about. That which leadership identifies as measurable naturally informs employees what metrics leadership thinks are important. The very act of deciding to measure something telegraphs your intentions. Inversely, the opposite is also true: people tend to believe what is not measured is not important.
All of this means leadership should be careful to identify what metrics are important because they define your organization and its behavior.
What should be measured?
First, an organization must decide what metrics are worthy and whether or not they are actionable. A lean approach is best here. Decide what does and does not matter to you, and then move confidently in that direction.
So what metrics are worthy to an engineering team?
A pull request has two major goals: the first is to improve the quality of code before you release it, while the second is to share knowledge between the team about the code base.
Pull Requests are great because they let your team have control over what goes into git; they let people comment about what and why things were done a certain way; and they can serve as permanent documentation about a chunk of code that can be useful down the road.
If we at LinearB were to recommend one metric to start measuring, it would be Pull Request Size. Measuring PR Size -- and using that measurement to encourage smaller Pull Requests -- will help drastically lower Cycle Time. It will encourage all kinds of good behavior around code reviews, and it will prove that metrics can have a positive impact on business outcomes.
Once you have identified the best metrics to track for your success, you will need to go about making sure they last. Here it is best to maintain a lean approach, avoiding large upfront investments of time or money.
How to make metrics stick
And you should, as a leader, as a manager, you should make people feel that you care. There is no substitute for that. - Luca Rossi, Dev Interrupted Podcast at 21:10
We have all worked at a company where a change was decided, people were excited to see the change and then, after a couple of months, everyone has forgotten about it. Metrics are no different. Once a company makes the decision to align itself with a metric it must make the effort for it to last.
It’s often best to start small. In the beginning, it is best to maintain a lean approach, avoiding large upfront investments of time or money. With small actionable change in mind, there are two ways to approach metrics adoption:
In a top-down approach you ‘ll want to speak with your senior developers early on. Give them strategic input to help them figure out the best way to implement metrics into your dev team. An engineering leader can then explain how the metrics fit into the company’s strategic direction and convey that message clearly to employees. It is important to get buy-in from your employees because they are the ones building value, and further discovering what can and should be measured. When done correctly, the top-down approach will have managers saying, “Wow, I’ve always wanted to measure this. Now I can.”
In a bottom-up approach, it’s all about making your team understand what you want to achieve. Provide them with the initiative to build value so they understand why and how they are being measured. For instance, most developers can relate to a bad pull request experience - one that takes way too long or one that has a poor review and causes issues during production. People understand that a good code review should be both fast and accurate. So by starting small with a metric that is already understood, you will gain buy-in from your team. When done correctly, the bottom-up approach will have employees saying, “Wow, we didn't think we could measure this, and it's actually valuable.”
How you approach adjusting for change in the long-term is up to you. In an ideal world, both the top-down and bottom-up approaches would be utilized simultaneously.
Most importantly, your people should know that you care and that you value their feedback.
Bottom Line
To achieve future goals a development team should know where it started. Metrics provide that benchmark. They are a foundation on which future success and business alignment can be built.
Furthermore, in engineering, just as in life, tiny improvements are staggering when tracked continuously over a period of months and years. These gains boost team confidence and collaboration.
Because with continual improvement, people feel as if they are working within a team and working as a team. When things go right, and everyone improves together, bonds are formed.
I included a few quotes from Luca Rossi above. He has a great blog for those who are passionate about engineering. You can check it out here: https://refactoring.fm/
Join the Dev Interrupted Community
With over 2500 members, the Dev Interrupted Discord Community is the best place for Engineering Leaders to engage in daily conversation. No sales people allowed. Join the community >>
In a company with 100 employees, there can be over 10 individuals with some form of neurodiversity such as ADHD, Autism, Dyslexia, or others.
While neurodiversity exists on a spectrum of intensity for each person, it’s still a significant number of people that could easily not be able to be working to their full potential because of poor accommodations. And according to acas.org.uk, 1 in 7 adults are neurodivergent. So how can you help make your teams and offices friendlier and less hostile to these employees?
Fresh from the Dev Interrupted discord, we’re taking a look at what the Dev Interrupted community has to say about handling neurodivergence in the workplace.
Hold open dialogs with your employees
“I'm the neuro-divergent individual at my work. ADHD and Anxiety disorder. After my concussion last year I now have vertigo. The big thing is overcoming the stigma and asking for what I need (and being honest with myself about what I can do). I've found my employer very accommodating. I would suggest that companies have open dialogs about it so employees are comfortable to come forward.” - Discord member JimMCKeeth
An open dialog with the employees of your company and teams regarding neurodiversity can indeed be a great help--Not just for anyone who is confirmed to be neurodivergent! Awareness makes it so that people can learn how to accept, understand, and work with people with neurodiversity.
Reducing stigma and myths regarding certain disorders such as ADHD, where one common belief is that adults cannot have it because of the mental image of ADHD only being present in young hyperactive children, is highly important! Knowing that your team members can understand how you function and how they can best approach you if you’re needed for something can prevent a lot of unnecessary distress and conflict.
As a simple example: Imagine that you have a colleague named Brian. Brian has problems switching tasks on a whim because of his ADHD. He needs to mentally prepare himself for each task and carefully convince his brain to focus on the task at hand.
Now imagine that you have an impromptu meeting, and Brian has to be there. The meeting is happening right now, so you go up to him and tell him to come to the meeting. Brian had no time to mentally prepare for a task-switch, and may be left frustrated and unfocused afterwards.
So what should you do instead?
Let’s say that Brian told the team that he has trouble suddenly switching tasks, and requested that you avoid making him have to do so unless absolutely necessary. Instead of having the meeting happen right at the moment that the majority agreed it would happen, you could agree to have it happen in 5 minutes, and give Brian a heads up.
5 minutes can already be enough time for Brian to be able to mentally prepare to switch tasks, as he can then finish up the segment he was working on and move onto the meeting instead.
Of course, Ideally, you’d have most of your meetings planned out a few hours before they happen instead, as that way you can prevent having to cause any potential issues in the first place.
I can personally say that being aware of the difficulties my colleagues can experience, and them knowing what difficulties I may have, has made our ability to work together much more smooth. It’s far too common for people to experience constant frustration because we’re expecting to be talking and working with neurotypical people, however by being considerate and understanding towards each other's struggles, we can reduce friction and create a more positive experience for everybody involved.
Actively support the individual
“I had an employee a few years ago with PTSD from time in the Marines. We worked together to make sure that he had a place where he could work, and also to make sure that everyone knew how to understand him. He is a great guy, but could seem severe and prickly if you just looked at him, which tended to keep people away from him. Communication with those he worked with, and some really easy interventions on my part, helped him to have a very successful time with us. I remain friends with him today.” - Discord member Drdwilcox
While making the team aware of how to go about handling neurodivergence is one part of bringing a comfortable environment, it is equally important to give focused attention to the employee in question. Approaching them when they seem to be struggling, working together with them to see what could help them, and discovering what their needs are.
This is something that I wished had happened more throughout my own life, even before I knew of my own ADHD, because even if you don’t know that someone has it you can often notice that something is off when looking at how they’re performing. And usually, they’re underperforming!
Even if you know that none of your employees or colleagues have any disorders, it never hurts to check in with them when you can and make sure that nothing is holding them back. As a review study of burnout prevention programs states, 80% of all programs successfully reduced cases of burnout in individuals. Imagine how much help individualized support could provide!
Making the workplace less hostile
Open-plan and noisy offices, my mortal enemies.
Many people can tolerate an open plan office that often comes with an array of little annoyances, some even actually quite like it for the social aspect. But they’re poison to people with ADHD, who already struggle with keeping themselves from being a distraction from their own work.
It doesn’t help trying to hold your developers accountable when there’s distracting noise being made. So what sort of accommodations for ADHD can you provide?
“I hate asking people to stop making noises. So I don't, and when I can't take it anymore it comes out in bad ways, like giving people dirty looks. Yes, we can talk to people, but then I'd be doing it all the time. And I might be the only one, so now I'm that guy who's always bugging people. Why not just ask people to be considerate? Take off your headphones and put them on the desk. Can you hear any noise out of them? Then they're loud and everyone else can hear them.” - Discord Member Scothannen
Confrontation can be a difficult thing to do for people that have disorders that affect their ability to socialize, such as individuals with autism. Having to constantly tell people to be quiet or to tone something down is a lot of work and can also strain relationships with coworkers who might just get annoyed- Especially if there was no agreement regarding noise in the office.
If possible, having a space where employees can move to that is meant to be total silence is one solution. A quiet room--similar to how some trains have silent cabins. If you want to be in an undisturbed area, you can go work there instead of the main area. This isn’t a realistic solution for every company though, some simply don’t have the space to do this or need high-powered workstations versus a portable laptop.
Providing noise-cancelling headphones is another solution, but that comes with the problem that people will come by to disturb you by tapping you on the shoulder instead. Perhaps having a simple “Do Not Disturb” card that is easily seen on the desk, where there is a mutual understanding to not go and tap the person on the shoulder. That way one can differentiate between a colleague that is alright with being disturbed while having their headphones on, and a colleague that really isn’t.
All in all, it all boils down to three words: Communicate, Support, Reduce. As long as you can actively communicate with your team about neurodivergence, and you actively offer support and look for feedback from neurodivergent individuals, you’re already taking several steps that many would never even consider. With time and experience you can then learn and work on how you can prevent any issues that your neurodivergent coworkers could end up dealing with, and while it may be impossible to completely eliminate a problem you can certainly reduce the stress.
Join the Dev Interrupted Community
With over 2500 members, the Dev Interrupted Discord Community is the best place for Engineering Leaders to engage in daily conversation. No sales people allowed. Join the community >>
