Learn, and Empower Others to Learn!
It often seems best to look out for another job to learn more, or better yet to learn more to get that new job. Often, it seems best decision to always hire people to fill the tech void within the company, and seems a waste of efforts to let people learn those new skills. Well, let me show you some of the positives which you’ve been missing out on, so far.
Technology around us is changing day by day. What was the norm yesterday is “un-cool” and outdated today. Newer projects are being written as you read through this blog. Every new project is trying to use the next-gen tech stack (if not the very bleeding edge technologies) in order to keep up, or at least try to. Some of these projects are also inventing new tech as they go, thereby complimenting the tech ecosystem . This trend is an over simplification of the theory of Diffusion of Innovations — by Everett Rogers, and Gartner’s Hype Cycle.
As a result, the demand for developers well versed with such ‘new(er)’ technologies is increasing by the day (if not by the hour in certain cases). The companies are expecting devs to know more (than ever) and the job descriptions are getting heftier in their expectations. In turn, this is creating a serious deficit of talent in the pool, which in turn impedes the recruitment for a company and even worse, makes the projects compromise on the right tech stack that they could/should have used.
So what do we do about this ? Well, encourage learning on the job more than ever!
What’s in it for the companies ?
Investing in people often results in the best returns for both the company and its employees.
- Existing devs already have domain context. Eric Evans explains the benefits of thinking in terms of bounded contexts in a quintessential manner in his book Domain Driven Design. Adding new tech skills in the arsenal beside domain knowledge is a proven winner in solving real problems pertaining to the company/business.
- Companies which empower learning on the job, are often the companies which attract and work with some of the best minds in the industry. People who are able to adopt and apply newer knowledge are often proven to be ahead of the evolution curve and generally layout the future path for others through their thought leadership. Conducive environments for these people is simply a ‘straight flush’ and a win-win for both the devs and companies. Continuous improvement (kaizen) and meaningful innovation is the key to success and sustainability for every tech company (product and consulting alike). People who are curious to learn play the biggest hand in making this a reality.
- It generates a path of learning and career growth within the company. It encourages people to challenge themselves in a healthy fashion and keeps them from falling in the ‘comfort zone’ trap. There is nothing more harmful than a cohort of staff which continues to ‘not’ reflect and think alternatives to what they’ve been used to.
- With the new(er) stack, there are only so many devs experienced in it, and even lesser ‘available’. Everyone is already going after them. And why should these devs leave their current environment which helped them be who they are, in the first place. Imagine you empower devs in your org to achieve that. Not only you don’t have to keep scratching your head figuring out how to ‘lure’ them in, but you’ve also managed to create a sustainable phenomena on your own. Imagine not having to stall projects because of unavailability of devs. Imagine not having to go empty handed in the meetings with your VPs/CXOs and disappoint them by telling them that their brilliant idea won’t see the light because you don’t have people to execute it. Imagine not being afraid in choosing the best stack suited to solve your problem. Imagine NOT BEING CONFINED!
What’s in it for the developers (YOU) ?
- Software engineering is akin to craftsmanship. Like almost all the other arts, its also majorly self-taught. Its imperative that you focus and keep investing in yourself. The day you choose not to learn anymore, is sadly going to be also the day you’ll stop being of much value. Don’t!! Grab a new book, follow a new blog, listen to an exciting keynote, write a ‘Hello World’ in new… BE INSPIRED!
- Stand out from the crowd. Become a thought leader. How frequently do you Google (yes, I’m aware of duckduckgo. And no!! I’m never using bing in a sentence) your answers vs answering others’ queries on the net/in your company? Get ahead!! Experiment, build hobby projects, share your wisdom, write a micro blog, tweet something interesting. The community needs more forerunners like you.
- There are high chances that you’re already surrounded by seasoned devs in your org. Having them play mentors for your learnings is a phenomenal idea. They might not be experienced with the stack that you’re chasing after, but they must have done this for themselves when they were in your shoes (or they’re still doing it). Having such mentors can make a world of difference to how you approach learning a new stack. They can pitch in the pragmatic ways and often warn you of the unknowns that you might not be looking out for.
- You need ‘more’ to get to the next level. You’ll need to own more responsibilities than you do now. You’ll have to guide and mentor people. You’ll have to ‘serve’ more than you do currently. Are you planning on doing all of that without being better than you already are right now ?
‘Learning new’ is not just about learning that new shiny language, or knowing about that new reactive framework in town, or going DevOps crazy (maybe DevSecOps is the new big thing eh! Oh wait, it is!). Nope! it’s NOT JUST that! It can be even finding alternate ways of writing the same piece of code, learning better ways of refactoring without halting your stories further, finding alternate ways of structuring your tests (Does it surprise you if I tell you can write BDD tests without using a BDD framework ;) ), or even just brainstorming with your fellow geeks on what’s not so right in the architecture right now and what can be done in the least disruptive and continuous way.
Don’t be fooled by thinking that the next job is going to be better. Don’t be naive in thinking it’s just this project manager who is always strong arming you into doing more than you signed up for. Don’t be fooled by thinking that getting an expert on that stack is going to solve your existing problem.
Think about what’s the guarantee that the next job is not going to turn up the same? And if it does turn out similar, will you not be on the lookout again? Think about whether ‘that new geek’ that you hired, is not going to be obsolete soon in your environment, because after all people are not learning in your environment.
I’m not suggesting you keep lingering on to your job no matter what. Even if its near impossible to find time to learn, because lets face it, they hired you to DO the job and NOT to “waste your productive time in learning and not being the code monkey to just write off those user stories”. Yup, such floors do exist, unfortunately! But what I am suggesting is to give it a fair chance. I know there are some ‘awesome’ companies which have dedicated 1 day off, 80–20 rule (God knows when engineers will stop using this ratio!) and what not to let people explore and invest in themselves. And yours might be rather more humble. But its worth a try. Not all projects are the same, not all teams are same and not all times within the same project and team are same. Find the right opportunity and time and utilise it to the fullest. Better yet, use that time to fix things in your project or help them look at better solutions. Chances are you’re that catalyst which the company has been waiting upon to realise it needs to motivate people to learn more on that paid time.
On the other hand, there is nothing wrong with hiring people to fill in the deficits of knowledge pool. Its always good to bring in fresh perspective to already existing staff. However, whats wrong is to almost always prioritise this, over enabling people to learn new things. This phenomena is more prevalent in consulting companies which do project specific hiring to suit the dynamic clientele and projects. Please take note that people are going to stay even after the project is over (well, more often than you think :) ). Moroever, newer projects are going to come in as well, which may command a different tech set than the existing ones. If everytime we got out to hire a new batch, we might be jeopardising more than just the values and vision the company stands tall upon.
Don’t get me wrong here. I’m not concluding that a newer batch is not capable of doing so or they don’t come from a background where these values are already practiced and cherished. What I am trying to convey is that with the similar values and vision, every company has its signature way of materialising them in to tangible means, which creates its identity, and it takes time to get to know and adapt this mannerism.
If you have any Pro Tips on how to keep learning, or how to help people learn in your team/company, please do share/comment. If you have any other thoughts or there are things you disagreed within the blog, I’m more than happy to hear you out, discuss and debate :).
Nevertheless, let me leave you with the following thought:
If you have always done it that way, it is probably wrong.
— Charles F. Kettering
