Skilling-up is not optional. It makes the difference between organizations that keep moving forward and those that slowly grind to a halt. When development teams deliberately grow their skills, capabilities, and confidence, they become more resilient, innovative, and attractive to work in. When they don\u2019t, risks accumulate, stress rises, and progress eventually stalls.<\/p>\n\n\n\n
Today, I want to share my ideas about skilling up development teams. And no, I do not mean scaling up. Skilling up is about consciously and structurally improving the people who build and maintain software. It is about growing competence before circumstances force you to.<\/p>\n\n\n\n
In many organizations I worked with, teams are under-skilled. Skilled developers are hard to find, and hiring can take months. I have seen organizations slow down innovation\u2014or stop it altogether\u2014simply because they lacked the right skills. One organization lacked front-end developers. The front-end developer they had was asked to do tasks for the other teams as well. Others lowered their standards and allowed under-skilled people to work on critical systems just to keep delivery moving. That may solve a short-term capability issue, but it introduces long-term risk.<\/p>\n\n\n\n
When only a few people understand certain systems, dependencies pile up. Teams cannot easily take on important work because they lack the experience or specific knowledge required. Delays follow. Pressure increases. Stress becomes the standard. And when stress increases, people leave. Often, it is the most experienced and skilled people who go first. I still remember one assignment where the last senior developer resigned. Panic spread quickly. How would they replace that knowledge? What would happen to the systems no one fully understood anymore? That situation was not caused overnight. It was the result of years of underinvesting in skills.<\/p>\n\n\n\n
That is why I strongly believe skilling up is a must. When people are challenged and supported in developing their skills, work becomes more interesting. Teams grow stronger. Organizations become more attractive, not only to new hires, but also to the people who are already there. Most of us want work to be exciting rather than repetitive and mechanical. We want to grow.<\/p>\n\n\n\n
Over the years, I\u2019ve come to the conclusion that to keep skilling up manageable, you should focus on practices. I have grown very fond of that word. To me, a practice is a small container of knowledge, skills, and mindset that helps you perform a specific job well. Thinking in practices makes improvement tangible. Instead of vague ambitions like \u201cwe need better quality\u201d or \u201cwe should innovate more,\u201d we can talk about adopting or improving specific practices, like continuous integration or organizing innovation sprints.<\/p>\n\n\n\n
This idea took shape while I was running workshops on built-in quality. In those workshops, I ask teams to map their entire development lifecycle. Many people discover that they have never really examined it end-to-end. Where do ideas originate? How do they become running software? Where do feedback loops exist? Where are faults introduced?<\/p>\n\n\n\n
In the workshop, the goal is to improve built-in quality. We explore how to detect problems earlier and prevent them from recurring. We often add additional quality measures earlier in the process. And every time we identify an improvement, it boils down to the adoption of one or more practices.<\/p>\n\n\n\n
Practices also help teams respond to recurring operational pain. If deployment issues happen repeatedly, perhaps version control or release management practices need attention. If configuration errors keep appearing, maybe parameterizing build scripts or improving environment management is the right next step. These are small, focused improvements. They are much easier to plan, explain, and complete than broad initiatives labelled \u201cinnovation\u201d or \u201ctechnical debt reduction.\u201d<\/p>\n\n\n\n
By talking in practices, skilling up becomes practical. Daily problems can be translated into small interventions that help solve them and still contribute to larger organizational goals. Large ambitions are broken down into hands-on improvements. When we relate practices to company goals and explain how they contribute, leadership can steer more effectively. Strategy becomes connected to action.<\/p>\n\n\n\n
I am sceptical towards organizations that reserve a percentage of time\u201430 or even 40 percent\u2014for improvement without structure. Freedom without direction leads to scattered efforts. Teams may experiment, but without shared priorities, the impact remains limited. Practices provide that structure. They offer a menu of improvement options aligned with real needs.<\/p>\n\n\n\n
Teams can then decide how to invest their time: building new capabilities, solving structural problems, reducing operational friction, or preparing for future demands. Progress becomes visible. Success becomes measurable. And measurable progress can be celebrated.<\/p>\n\n\n\n
When leadership steps in constructively\u2014by clarifying which development capabilities must grow, which skills will matter in the coming years, and which practices deserve focus\u2014bottom-up energy gains direction. Improvement becomes coherent rather than accidental. Learning efforts align with strategy. This requires technology leaders to articulate and share a clear vision for IT development, one that includes both an outlook on industry trends and a perspective on where the business is heading. When this vision is explicit, it provides a north star for teams.<\/p>\n\n\n\n
For example, an organisation might state a strategic ambition to evolve towards a microservices architecture. Today, a comparable example could be defining and communicating a clear AI strategy: clarifying how AI will be used, what capabilities need to be built, and what role it will play in products and operations.<\/p>\n\n\n\n
Once this direction is expressed, teams can proactively develop relevant skills, experiment in meaningful areas, and invest in practices that support the long-term strategy. In this way, leadership does not limit autonomy; it enables it by providing focus.<\/p>\n\n\n\n
In the end, skilling up is a shared responsibility. Leadership sets direction, supports initiatives, and rewards progress. HR contributes by defining roles clearly, mapping skills, organizing training, and hiring people who truly match organizational needs. Product management plays its part by understanding where products are heading and which capabilities will be required tomorrow. Teams themselves observe trends, experiment, define learning goals, and communicate their needs upward.<\/p>\n\n\n\n
Running through all of this is one central idea: practices. They make learning smaller, measurable, and discussable. They enable prioritization. They make progress visible. They allow organizations to celebrate concrete achievements rather than abstract intentions.<\/p>\n\n\n\n
Whether the goal is higher quality, lower cost, faster delivery, happier teams, or future readiness, practices transform ambition into action.<\/p>\n\n\n\n
My call to action is simple: make your skill needs explicit. Align them with both your operational pains and your strategic ambitions. Embrace practices as small, concrete innovations, and make skilling up tangible within your own context.<\/p>\n\n\n\n
Create your own overview of the practices that matter. Discuss them. Prioritize them. Connect them directly to your strategic goals.<\/p>\n\n\n\n
When learning and improvement are grounded in clear, understandable practices, we bridge the gap between today\u2019s challenges and tomorrow\u2019s demands. We prevent knowledge from becoming concentrated in a few individuals. We reduce stress and fragile dependencies. We build teams that grow before they are forced to.<\/p>\n\n\n\n
Skilling up is not about reacting to crisis. It is about preventing crisis. And organizations that take this seriously will not merely survive change; they will shape it.<\/p>\n\n\n\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
Why skilling-up through small, focused practices is the key to building stronger teams, reducing risk, and keeping organizations moving forward.<\/p>\n","protected":false},"author":8092153,"featured_media":8105395,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_tec_requires_first_save":true,"_EventAllDay":false,"_EventTimezone":"","_EventStartDate":"","_EventEndDate":"","_EventStartDateUTC":"","_EventEndDateUTC":"","_EventShowMap":false,"_EventShowMapLink":false,"_EventURL":"","_EventCost":"","_EventCostDescription":"","_EventCurrencySymbol":"","_EventCurrencyCode":"","_EventCurrencyPosition":"","_EventDateTimeSeparator":"","_EventTimeRangeSeparator":"","_EventOrganizerID":[],"_EventVenueID":[],"_OrganizerEmail":"","_OrganizerPhone":"","_OrganizerWebsite":"","_VenueAddress":"","_VenueCity":"","_VenueCountry":"","_VenueProvince":"","_VenueState":"","_VenueZip":"","_VenuePhone":"","_VenueURL":"","_VenueStateProvince":"","_VenueLat":"","_VenueLng":"","_VenueShowMap":false,"_VenueShowMapLink":false,"_tribe_blocks_recurrence_rules":"","_tribe_blocks_recurrence_description":"","_tribe_blocks_recurrence_exclusions":"","ep_exclude_from_search":false,"_jf_limit_responses":"","footnotes":""},"categories":[883,890,908],"tags":[],"content_source":[],"class_list":["post-8105389","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-mindset","category-people","category-process"],"acf":[],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/posts\/8105389","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/users\/8092153"}],"replies":[{"embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/comments?post=8105389"}],"version-history":[{"count":3,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/posts\/8105389\/revisions"}],"predecessor-version":[{"id":8105393,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/posts\/8105389\/revisions\/8105393"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/media\/8105395"}],"wp:attachment":[{"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/media?parent=8105389"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/categories?post=8105389"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/tags?post=8105389"},{"taxonomy":"content_source","embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/content_source?post=8105389"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}