DEV Community: Vadim Kravcenko

Embracing Hacker Culture

Vadim Kravcenko — Wed, 01 Jun 2022 08:08:49 +0000

Back in the 1960s, in the dorms at MIT, very young and brilliant people got their hands on the first user-programmable computers. This is where it all started, “The Hacker Way,” the culture of tinkering with computers and achieving limited but remarkable results. This culture is also not confined to the software domain. You could’ve been a hacker if you tinkered with hardware. If you found new ways to perform art, you could also be a hacker. It’s all about the mindset and not about the tools.

The core concept of this culture was in trying and failing and trying again — while sharing the knowledge with your fellow hackers so they can build upon your mistakes.

Nowadays, the word “hacker” is used negatively, portrayed by the media as villains who rob banks and spread ransomware. In this article, I’d like to go back to the term’s original meaning — bold enough to build something quickly, test the system’s boundaries, and learn from the failures. Putting experimentation and innovation at the front of the company and eventually embracing transformation and not running from it.

Companies start with a “hacker mentality” — they need to release the product as soon as possible and find the product-market fit before the money runs out. Eventually, though, as the company grows, internal bureaucracy and the desire to mitigate risk start to overshadow real innovation. The company becomes rigid, transformation becomes complicated, and experiments non-existing.

I think this is where the companies go wrong.

Being a software company means being agile and dramatically speeding up the feedback gathering. Back in the day, companies could only measure their performance four times per year — imagine how many users would leave Uber/Airbnb/Meta if they would evaluate user feedback every quarter instead of deploying several times per day with a/b testing and new insights from data.

For the companies that consider themselves digital natives — innovation means having holistic hacker structures with fast ideas and cheap customer experiments. Hacker culture came into the business world with design thinking and lean startup methodologies. As old and well-established companies are eyeing the methods of the hacker way, this culture is changing how we work and how we do innovation.

But the hacker culture is not only beneficial for big companies like Netflix or Meta, or Google. The concepts can be adapted to any size company. Let’s talk about how you can lead your in-house teams of hacker entrepreneurs.

The Hacker Way

As I mentioned before, being a hacker is a change in mentality and a change in the processes surrounding you. The culture is catalyzed through a symbiosis between the hacker mentality — “I will make it better and more useful” and the high-growth entrepreneurship attitude — “I will experiment and make it worth it.”

So what does it mean to have hacker innovation inside your company, and what kind of culture do you need to embrace as a technical manager?

Step up and do it

If you see that something, be it a process, a module, or a system, is not realizing its full potential — go and fix it. Hackers believe that everything can always be better, and nothing is ever finished. There are a million different ways to improve things and a million different ways it can go wrong. Change always involves risks, and even the best hackers don’t always build the right way. But the benefits of the risks far outweigh the negatives of stagnation.

From the management perspective, it should be clear to the employees that they should not be afraid of changing the status quo. Encourage your team to make bold decisions, and tell them it’s OK to be wrong sometimes in pursuit of a better future.

Only if they know that you have their back will they be comfortable stepping up without you supervising them. This is where the constant improvements come from, a 1% improvement here, a 3% improvement there, and eventually, you have a new system that is far more efficient than before.

One thing you need to keep in mind about middle management is that they are often there to control risk, control behavior, and control chaos. This contradicts the hacker culture where the goal is to set boundaries and goals and then give the hackers the autonomy to do as they see fit “for the best of the company.”

You might think this is too much and will bring only chaos to the structure, but that’s not true. For example, if there’s a Product Owner, who acts as middle management, they don’t just let the team build what they want; they guide them in the right direction, but without controlling it per se.

There must be both dark and light. I will do what I must to keep the balance, as the balance is what holds all life. There is no good without evil, but evil must not be allowed to flourish. There is passion, yet peace; serenity, yet emotion; chaos, yet order. I am a wielder of the flame; a champion of balance. I am a guardian of life. I am a Gray Jedi.
Leor Danal — The Gray Jedi

Balance is key. From the management perspective, the boundaries need to be neither too loose — which makes developers lose focus — nor too strict — which makes people unhappy. This makes the life of Product Owners and alike complicated — managing hacker innovation means keeping everyone aligned and focused on:

Doing the right things means doing things relevant to the goal.
Doing things that have an impact — meaning solving the most critical problems first.
Not wasting resources — meaning doing stuff that moves the needle and not just playing around with the latest tech. Data beats opinion

As Mark Zuckerberg wrote in 2012 when Facebook filed for IPO: “Code wins arguments.” And as my business partner Jean-Paul loves to say, “Data beats opinion.”

In a hacker-friendly environment, it’s better to build a prototype and test the idea on real users and see what sticks rather than hypothesize and discuss what the feature should look like in endless meetings. In the end, in big companies, this risk-free innovation method might be helpful to some people who prefer talking rather than doing because then they can never fail:

If they talk and do extensive research and the project gets scrapped because it’s too much risk or hard to achieve — oh well, nothing lost, nothing won, no risk involved.
If they talk and do extensive research and then talk some more with consultants/contractors, etc., only the risk-free projects will survive and be paraded as trophies of success.

Hacking is an inherently hands-on and proactive discipline. Instead of debating for weeks whether an idea is viable or what the best way to build something is, hackers would rather build a quick prototype, gather real data, and see what works.

From the management perspective, in a hacker-focused enterprise, this means actual data should also drive decision-making instead of status and seniority. The information flow should be free from subjective interpretation until such creativity is required. Don’t let opinions from C-Level executives influence or much-worse contradict decisions made based on data.

Complete Transparency

A hacker is always open about his intentions and actions. No hidden agenda, no taking it personally — I did X because of Y, and I failed when I performed Z because of Q. More information equals better-prepared colleagues who can help tackle the problem.

This goes both ways, as hackers should be transparent in their actions, so should the company be transparent in things around the people.

At our digital agency, we try to be open about the why and the how of any strategic decision the management makes. We hold monthly meetings where we do several things:

First of all, we go through the decisions and our reasoning behind them. It doesn’t help if all your employees see — is the result of your reasoning without explanation. Share your thought process with them.
We share our deepest darkest secret — current financials. We do that so that everyone is aligned on what we need to achieve.

I believe in the open world, open data, and open APIs (especially open banking APIs). The more open we are, the better decisions we make and the more significant an impact we make.

From the management perspective, transparency means not shooting the messenger when he brings you bad news. Two main information streams are important:

Bottom -> Up Communication. Mostly negative signals. Where are the risks? And what’s happening that you should know?
Up -> Bottom Communication. Mostly positive signals. What’s good that’s happening? Who should be praised? Whose experience needs to be shared across all teams?

You either accept that failures will happen and you will know about them first, or that failures will happen and you will know about them last. Nurture a trusting relationship with your peers, so you constantly receive signals from your hackers about the status quo.

It also works the other way — when something good is happening, make it known, send signals to your hackers that their work doesn’t go unnoticed, that they’re doing great. Or if the developer is struggling behind — talk with him early and openly, point out the things that need improvement, and if nothing changes and they are fired a few months down the road, it will not be a surprise for them.

Competence above all

Developers are the ones who actually create the software that powers the company. These hackers are inside the engine room shoveling the coal, keeping the whole ship running. They need proper tools, skills, and knowledge to make sure they can deal with everything that comes their way.

you should have a team that contributes proportionally

To maintain a proper pace, developers should have nothing distracting them other than the challenge they are currently facing. The tools, the hardware, the supplies — the management should provide everything.

In such an environment, it’s easy to distinguish people who are more “attitude” than “competence.” It’s also important to reward those with competence and punish those with “attitude” as that has no place inside the engine room.

Hackers are not kids who need babysitting, and you’re not a kindergarten teacher to deal with the drama. Hackers themselves value peers who prove themselves and distrust people who are dragging them down. As a manager, you’re doing a disservice by keeping people who are not performing to your team’s standards.

The hard work and dedication developers put into understanding and fixing bugs should be rewarded by having only the people who contribute proportionally to the team’s effort.

Conclusion

Times have changed a lot since the initial hacker term was introduced. Today software is not something that only a few companies have, and automation is not something only the big enterprises implement. Even the most conservative domains are switching to a software-based approach with innovation.

Software and general advancements in AI are unstoppable forces that will, with time, make any behemoth submit to them. To survive, enterprises must ride the wave of fast pace innovations — getting clever hackers on board and looking for new ways to solve problems.

There isn’t a company in the world that can live without software, and soon most companies will have their in-house software product. Instead of hiring people who only talk about building products, hire hackers that do and embrace the culture.

Read more essays by a veteran CTO at vadimkravcenko.com

How to deal with complex projects

Vadim Kravcenko — Tue, 20 Jul 2021 13:11:40 +0000

This article was originally published on my blog, where I write about being a technical advisor to early- and mid-stage startups.

As a founder, one of the underrated skills is to know how to deal with complex projects and build complicated stuff. Whenever you start a project, you usually have a good idea of how difficult it will get. If there are challenges to be solved, you can see possible places to look for hidden complexity – this comes from experience.

Over the last ten years, I’ve built projects of different complexity – mobile banking apps, finance tools, ordering apps, running apps, you name it. But even with such experience, some projects still fail. I would never agree to handle a big project alone. It’s always the effort of many people that keep the project from falling apart – it’s not a one-person show.

There’s always complexity hidden in the projects.

We know why projects fail – there are multitudes of books/articles/studies on why software projects fail. We know how to prevent their failure – so why do they still fail?

I don’t know why projects fail in general. That’s the simple answer. Every startup is building its megaproject, and it is unique and has its flaws, and you learn how to adapt and make sure that it’s done on time and in the correct way.

I’ve split this article into several sections:

As an early-stage founder, what necessary soft skills do you need to cultivate.
Things that I do day-to-day to move a product forward.
Most common issues that you will face.
General tips for indie hackers or early-stage startups on managing your product development.

The easiest way to build a complex project is to reduce complexity. That’s even more true if the timeline is tight.

Before we dive deep into the nits and bits, I’d like to clarify what exactly I consider as a complex project – these are projects that require cross-product integrations with aggressive deadlines and multiple Agents involved. They don’t necessarily need to have huge codebases, as that’s not what makes it complex – it’s more about everything around the project that makes it difficult – difficult people, complex processes, consultants all around. An early-stage startup that is solving a single problem can be considered a complex project.

Soft skills to manage projects effectively

As many will tell you – building software products is less about coding and more about everything that revolves around it. These three character traits can have a profound effect on success.

Expect the unexpected and have a plan B.

Try to be as flexible as possible – get ready for unexpected things to happen. When planning a timeline – assume people will get sick or leave the company, consider that the freelancers will not deliver on time.

There are multitudes of factors that are out of your control when you’re building a product:

People get sick
People leave you
Freelancers overpromise and underdeliver
Contractors fail to meet the deadlines or goes entirely out of business.
The complexity of the project increases with new requirements.
Of course, you can say – but I have it in the contract that these things shouldn’t happen. A contract can help you when you sue them six months later, but here and now, it has zero influence.

These are all improbable events, but I hadn’t had a single project where at least one of the above things didn’t happen. So a good rule of thumb – trust Murphy’s Law – “Anything that can go wrong will go wrong.” Managing a project is the same as managing life – you can’t have everything under control – mostly, you ride that chaos wave and hope it’s going in the right direction.

Failure is the rule, not the exception, in large-scale IT projects. I’ve read a study some time ago that says that 45% of the projects run over budget, 7% of the projects run over time, and 56% of the projects deliver less value than planned.

A more “developer-friendly” example: Your team wants to build a payment integration. Sounds straightforward as you were planning on using Stripe, which has excellent documentation. But then, during the development, you find out that Stripe doesn’t allow selling weed-based products through its platform. So you search for a payment provider that does allow it. But this provider doesn’t have a REST API – it only has SOAP. The whole processing of payments is different, leading to additional handling of currencies and orders, resulting in more chaos in the project.

Get ready to make hard decisions.

When something unexpected happens, it’s crucial to make decisions and to make them quickly. You’re accountable for all the choices that you make and also those that you do not. Being indecisive is a one-way ticket to a failed project.

On the one side, you need to gather as much data as possible to make an informed choice. On the other side – you don’t have the luxury of spending too much time on it. Any decision is better than no decision at all.

My thought process during some unexpected crisis is as follow:

You get hit by something unexpected. It happens, no way around it—time to squeeze the lemons that life threw at you.
Don’t look for excuses or someone to blame, no time for reflection on WHY it went wrong either – you can do this after you have the situation under control.
Start asking yourself the essential questions – How does it affect our endgame? What are my next steps? Who can help me decide what my alternatives are?
Start planning the measures that can solve the issue. As I said – make a plan A and then a few more just in case.
Make it a priority and discuss it with the key people involved.
After solving the problem – start documenting why it happened and what you can do not to allow this to happen in the future.
Time to have some rest.

Managing a complex megaproject is similar to managing a crisis

Learn to talk to people

So as you see from the two points above – communication is one of those skills that you’re going to have to master to be a good manager or just, in general, to lead product development.

You’re going to have many discussions of the underlying problems without pointing fingers and blaming someone. It’s a skill to keep the conversation civil and focused on the task. Too many times have I witnessed the passive-aggressive pushing of blame to avoid responsibility instead of accepting the failure and moving forward.

One thing to mention, from experience, when dealing with big corporations – remember that they will be playing politics to get maximum value from collaboration with you. There’s no way around it. Just try to learn enough of it to navigate it, but don’t get sucked into it.

Staying on track single day at a time

Any big project always requires a lot of work. Here are some things that can make your life easier when dealing with the chaos that complexity brings.

Before you start setting up the team, the responsibilities and tasks define the business problem you’re trying to solve and outline the value in solving it. It doesn’t have to be too detailed, just the high-level stuff. Talk about the vision of the end product – discuss it with your stakeholders, make sure you don’t forget anything. When making a mobile application – build a persona, do scoping canvas, talk about features, prioritize them, think about user flows. Everything you do know will make the work later easier.

“If you don’t know where you are going. How can you expect to get there?”

A good practice is to conduct interviews with your audience as soon as you defined some form of the product. Many tools on the web allow you to select people based on criteria that suit your product persona. Talk to your target audience, whether internal or external, so you fully understand the problem space and gather information on it. Find out edge-cases, things that people expect, ways to build them.

After you have an idea of what you’re building, let’s take a look at the timeline.

It’s good practice to start from the release date and go backward. Discuss the interdependencies of the sub-projects. Does something need to be finished before the next phase starts?

For example:

the content needs to be completed before the development starts.
The designers need to finish the UX/UI before development kicks off.
The UX/UI needs to be greenlighted by the stakeholders.
The functionality needs to be signed off before the UX starts etc.

Usually, there are quite a few dependencies, and not everything can be done in parallel, even in big teams.

After defining the time scope – it’s time to gather the A-Team.

You always need your best people working on complex projects. Make sure a suitable team member covers every part of the project. Empower them to be the decision-makers and take responsibility for their tiny island. There’s no need to micro-manage every aspect, as long as you have the big picture view (and of course, you need to trust your colleagues).

The team is what drives your success. Focus on empowering the people around you.

Make sure everyone knows who’s responsible for what, who can make what decisions. Here’s it’s also vital to define communication channels and intervals. For example, you say that you will have a meeting every week on Thursday to go through the latest activities from different departments and everything that went wrong. People need to be aware of the problems- to deal with the unexpected as soon as possible.

Start iterating. If you’re building something in an agile way, then the product is never finished; you finish one of the iterations. Get ready to build and rebuild based on feedback.

No amount of testing can prove a software right, yet a single test can prove a software wrong.

All the assumptions that you made, the rules that you tried to skip to deliver faster – all of that will surface during the alpha-release.

To make this period less painful, you need to schedule some time before the release for beta testing, a week, maybe even a month, depending on the release cycle and the size of the Software. You will still get a considerable bug list regardless of how well you test. Testing is not meaningless, though – the more you test, the more bugs you’ll see and the more bugs you can fix.

Most likely issues during the early stages.

I can summarize the possible issues that you will face into three categories:

Business issues – This includes the time-to-market and limited resources.
Management issues – This includes things like lack of oversight and over-optimism.
Product Issues – Bad technology choices and flawed estimations.

Business Issues

The business side always wants to have the highest quality in the shortest amount of time. As a person from the technical side, you always need to push back on that, as you know – the faster you go, the worse it gets. Shortcuts in implementation, skipping testing, forgetting documentation – the usual consequences of tight deadlines.

You either cut the scope and keep the deadline or keep the scope and push the deadline.

There are always limited resources available. Of course, we all want to work on multi-billion projects with unlimited budgets. Sadly, that’s not how it works, as the budget is usually the one thing that investors tightly control. Everything money-related will need to be justified, and the decisions will be under scrutiny.

If there are consultants on the project – they will try to minimize the costs to show that they are squeezing the maximum efficiency out of the teams.

Even though the resources you will have available are limited – the business will think that anything is possible. That’s a common misconception in IT. Example from High-Frequency Trading – if there’s a requirement to keep the latency below 20ms, but you are sitting in Europe, and the Server is in China, things get tricky. Push back on things that don’t make sense from the technical perspective.

Management Issues

Delegation is cool. Letting people run wild isn’t. If you give people the chance to slack off, they will take that chance. This doesn’t mean you should micromanage everyone, but you should instead define clear goals and make sure that people get there without causing too much trouble.

For example, suppose one of the stakeholders takes too much time with some critical decision blocking your development teams. In that case, it’s essential to step in and remind them that there are deadlines and the project needs to be moving forward.

Speaking of deadlines – be realistic or even pessimistic when planning. The problem with being optimistic is that if you think that each task will be finished at exactly the time allotted, then a single hiccup somewhere in the chain will result in everyone missing deadlines. Each mistake accumulates as an avalanche effect:

Someone forgot to send an email – people don’t know what to do.
A decision is unmade.
A manager is afraid of taking responsibility,
and bam, you’re behind your deadline by a week.

The complex projects are usually multi-year contracts. This means people tend to relax during the first few months. The closer it gets to release, the more they start running around like bees. So my rule of thumb is – act as if the release is next month and solve problems with that state of mind.

Product Issues

One of the most common product issues is that no one knows what the project’s vision is. Or worse – some stakeholders have conflicting interests – both want the product to succeed but in different ways. This is when politics start. Everyone will be pushing their agenda. Again, when it comes to politics, I try to stay away from it.

Nobody would force a builder to build the basement after having finished the roof, but in the software industry, that is standard practice.

The second most common thing is that a change request later in the project requires rewriting the core functionality. Of course, with agile development, you rarely have the full specification of the product when you start developing. Otherwise, it would be waterfall development and not Agile.

Other than that – unless it’s an entirely new project with no dependencies, you will have to work with some legacy system that lay dormant for ages. Sometimes you find relevant parts with zero documentation, and no one in the company knows how it works. It’s better to evaluate the legacy system before the development starts and calculate the time to build/migrate/extend the legacy code.

Managing complexity is like solving several different puzzles at once

General Tips

I’ve gathered a few valuable tidbits of advice over the years. I think you will find them helpful also:

Document everything

It’s crucial to have everything in writing – all the information regarding who does what, who’s responsible for what, who built what, how the Software works, how it should work, or why it doesn’t. As long as you have it on paper, you can always come back and reflect on what you did and why.

Revisit plan at regular intervals

If you’ve successfully finished some part of your Software – review how the assumptions you made earlier changed. Make sure no new issues have arisen going forward from this milestone. Talk to your team. With the new knowledge that they have – do they see any problems now that some part of the project is complete?

Be transparent and honest. Communicate progress on time

Set up regular reports with the key stakeholders so that you can tackle issues and manage expectations proactively. These could be written or through any channel that you defined.

Keep your options open.

You don’t know from the start in which direction the project will evolve. So it’s impossible to prepare the “core” for all possible deviations from the initial requirement. Prepare to be flexible, but don’t start over-optimizing too early.

A megaproject is a combination of predictable, standardized, and repetitive tasks performed many times before and novel and innovative procedures being applied for the first time.

Do your homework. Always.

You may be building something you’ve never built before, so it’s essential to do research and talk with someone more knowledgeable. When performing risk assessment, where are the pitfalls/shortcomings? Find out all the ins and outs of the technology that you’re using. How were similar projects built? Are there any case studies? This is especially true for software engineers that need to get their estimates right – the more you know, the more accurately you will know what to expect.

Try and reduce the number of parties involved.

Multiple agents (subcontractors) always increase the complexity of the project. The best-case scenario: your company can do the whole project alone, which sadly rarely ever happens on megaprojects.

If you can’t reduce the number of agents involved – strictly control all the communication. Otherwise, it will get out of hand quickly. Clear structures help everyone know where they sit in the hierarchy and who they need to talk to to get things done, e.g., change approvals, resources release.

Frequently asked questions

1. What’s the difference between software projects and other engineering projects?

The main difference is the number of changes during the execution of the project. For example, if you’re building an airplane, nobody will tell you that they want it to go to space in the middle of the project. But in the software industry, this is possible. This goes hand-in-hand with the logic of business that anything is possible in IT. If you built something that flies, then it should fly anywhere we want it to.

2. How to estimate a megaproject?

The task of estimation is a crucial one, so take your time doing it. This is where good technical spec can help you a lot.

First of all, never estimate a software project by yourself. It’s good practice to have at least several teams assess the project and then take the average number of hours for reference.

Second, split the project into modules and modules into tasks, estimate the tasks, and sum the person-hours needed for the functions and modules. The rule of thumb is people only count the raw development time, forgetting all the small things that add up in between, so add another 20-30% for unexpected bugs. Communication will also take a few hours per week. Then there’s the Scalability requirements, Security requirements, Performance, etc.

3. Can I trust the developers to meet their estimations?

This is a tricky one. If a developer estimates the task will take 30 hours, can you trust him to deliver finished work in time and up to the standards? To be honest, you shouldn’t. If a developer says he will do this task in X amount of hours, you plan it as X + 20% hours internally.

The reason is that the developer may not see the whole complexity from the start and will only notice how hard it is after starting. I can not remember how often I created a task that seemed easy initially but was quite complex after the second glance. Consider a job to build a currentTime library that returns the current time. It seems easy enough, but then time zones come into play, then suddenly some countries decide they’re not doing Daylight Savings anymore, and the spiral continues.

Moving forward

As your startup grows, the project becomes less chaotic and more defined. Processes get added, procedures get documented – you have either adapted to the chaos, built that first version of the product, or you failed. Still, even then, you have gained valuable knowledge that will allow you to build your next endeavor better and more efficiently.

In conclusion, I want to say – never say NO to building something extraordinary. It’s always a win-win situation. If you fail – you learn. If you succeed – even better.

Follow me on Twitter as I build my consulting business in public, or let me know if you need a technical advisor – I might be able to help you out.

Building your remote team

Vadim Kravcenko — Sun, 27 Jun 2021 19:31:47 +0000

This article was originally published on my blog, where I write about technical stuff that could benefit early- and mid-stage startups.

While there were many skeptics of remote workspaces a few years back, most of the companies in the last year had to try out remote work in one way or the other. To their surprise, the effectiveness of the people did not drop when they worked from home. Who could've thought? In my opinion, a decentralized, remote workforce is the future of the digital economy.

Winning at the remote game means building your company in a way that empowers the employees, establishes self-sufficient teams that function autonomously with little supervision. Of course, the whole concept revolves around trust, but hey, if you don't trust your employees, that's another issue.

There will always be people who abuse the system, abuse your trust and try to game the mechanics for their benefit. That's fine, as soon as you find these people, let them go. However, they probably need a stricter environment to function correctly, more robust control over their work - meaning they thrive when someone is looking over their shoulder. A remote gig is not a good fit for these kinds of people.

Try to focus on the employees who thrive in such environments rather than those few bad apples. I will elaborate later on some tools that you can use to mitigate the most common pitfalls regarding trust, but we'll come to that later.

Over the years, I've had the privilege to be part of fantastic remote teams and building some myself. So here are a few tips that I put down together that would be useful to an early-stage founder that wants to build a remote workforce.

Disclaimer: It's all subjective, my thoughts, my methods - what has worked for me may not work for you, but I'm pretty confident it will help you.

I'm going to split up the topics into four categories, which I think are the most important when you have remote teams:

Onboarding: it's always hard to start at a new company, much so for remote workers. I've had situations where our team members left because they were not appropriately onboarded and felt lost.
Day-to-day business: We'll discuss methods that make life easier when you don't see your employees every day. Small things that may seem unimportant but have a huge impact.
Culture: There's no way around it. To make sure people want to stay with you - you need to keep them happy and engaged.
Results: I'm assuming you're not a charity and need something done, rather than have people work for you just for the sake of working. This chapter is where we'll be making sure that the team delivers and pushes the company forward.

Onboarding

Imagine your first day at the office - you come in, everyone smiles, you get introduced to people, brand-new faces, new coffee machine - by the end of the day, you feel pleasantly exhausted from all this information.

On the other hand, imagine a remote developer who starts at a company with poor onboarding - same place - he's still in his living room with his computer - no introduction, just a 10-minute meeting to talk about the project. You feel exhausted and lost - what should you do, where should you start. What's happening?
Let's try to avoid such situations, they are unpleasant, and no sane employee will want to stay with you if you treat them like that.

We can avoid them simply by preparing for future hires:

Start with implementing proper onboarding processes. This means having a standard procedure for introducing a person to the whole company and to the team where he will be working.
Assign a mentor/guide who will be the go-to person for the first few months until the person gets settled in.
Have an employee handbook - all the stuff that the person might need to know - your principles, work ethic, etc. EVERYTHING needs to be in there.
Have some documentation of the project on which they will work. * Set up a meeting with the product owner to understand the project's vision, then with the team members to dive deep into how they are implementing this vision. What challenges are they facing?
Keep it personal, or at least make sure that the system is in place to make the person feel welcomed. Engage with him, guide him through his first few days. For example, at mindnow, our digital agency, we have "Your first week" and "Your first month" articles in our knowledge base - basically, a step-by-step guide on adapting to the new environment and what you need to know, etc.
Learn from your new hires - the onboarding process doesn't stay constant; it improves with every new employee, who brings in something of his own and enhances the knowledge base through his own experience. For example, maybe she thinks there are not enough meetings with the team members to understand the project or this project is too big to get to know in a week. All feedback is essential.

I remember I had a software engineer who left the company after only two months - I got devasted. So I dug deep into what went wrong, what did we miss, how can we improve. In the end, this resulted in us making drastic changes to our onboarding, and we never had such incidents ever again.

Every employee that leaves due to flawed processes is a failure on your part as a business owner.

Day-to-day business

Now that we have the person properly onboarded, it's time to think about communications in a remote environment. In an office, you're aware of your surroundings and can quickly call a 5-minute huddle to discuss some important topic. It's practically impossible with remote employees - you don't know if they're deep in their work or if they're already on-call with someone or just went to take a shower.

The first thing to do is to set up a system for asynchronous and synchronous communication. For example, for synchronous communication, there should be rules for how you organize meetings:

The inviter should communicate a clear agenda and goals as early as possible. People should be able to prepare for the meeting.
Only the relevant people should be involved. What's the point of having a person in the meeting who does not bring any value.
Someone should take notes and document action items. Everything that is not explicitly defined - can be regarded as forgotten.
Send out a summary email after the meeting to keep everyone informed about the decisions.
Everyone should always be on time and with a functioning camera. * It would be best if you were an example here. If you start showing up a few minutes later, everyone else will begin showing up later also.
Stable connection to avoid situations when you're feverish talking about the vision only to hear "I lost you there for a second"

For more asynchronous communication, I would recommend using Slack or Microsoft Teams. It's more of a preference; either is fine. With a remote team - this is where you will be having most of your communications.

Async communication is where your employees can get burned out quickly. People work in different schedules, and there might be notifications during the evening or on weekends. For example, a notification for a developer might mean a message from a product owner that says something broke. It's a source of anxiety for some people — set up strict rules when notifications should be disabled and alternative communication methods if something is on fire.

Once you have the communications figured out - it's time to switch to a more exciting topic - automation. We need to remove as many nuisances as possible from the daily lives of the developers.
The less time they spend thinking about tests, meetings, code style, etc. - the more time they have to focus on the crucial tasks - architecture, complexity, coffee.

Automate everything, integrate everything, join your different services (HubSpot, Jira, HR Software, Monitoring Software ...) into one big hub. For example, Daily standup via Slack, Jira summary message in Slack, Linters, Continuous deployment with Slack notifications, Automatic Tests on branch push.

Automation also means documenting processes, so the developer doesn't have to spend 3 hours to figure out how to do something. Imagine if you don't know how to do something in an office environment - it's much worse when you're alone. So instead, every complex process needs to be written down as a step-by-step guide (preferably with pictures) and shared with everyone.

One solution to the problem when people focus too much on their projects is a Fix-it-Friday. A day when a developer can do anything good for a project/company (if the project is not behind deadline, of course). That means he can forget about the tasks and focus on refactoring, implementing a new library, discussing architecture, rework the deployment, improve the documentation, add some automation that would benefit the company. Possibilities are endless if you empower people.

In the end, the more resources you invest into proper processes, proper automation, proper documentation, the easier it will be for a remote dev to work on your projects.

Culture

Culture is crucial. How you empower employees and trust them will be one of the factors that will impact your team's output. What kind of environment you set up is how your team will perform. If you have an environment where you give your colleagues autonomy and decision-making tools - then your team will thrive without you micromanaging every step of their way. Trust your employees to make good decisions and hire intelligent people.

Keep everything transparent - the feedback, the decisions, the mistakes, the praise. It's easy to hide when you're remote, be silent when you need to speak up or forget to praise your peer when you don't see him face to face. Be an example of transparency - write in channels instead of private messages, take ownership of your mistakes, share management decisions with all employees, give praise publicly.

One aspect where the culture suffers is if you have a hybrid team - part of the team is going to the office, part of the team is remote.

A hybrid company tends to put the remote workers at a disadvantage - they get forgotten, decisions made without them, it feels underwhelming for the people who are not part of "it." Invite everyone to company retreats, go somewhere together, if you're present in several countries - let your employees visit different offices. Meeting each other face to face periodically has a considerable effect on morale.

Keep track of the mental health of your employees. The line between work and life gets blurred when you're working from home. Make sure your employees know that it's OK to turn off notifications. It's OK not to respond immediately in the evening. Let them recharge during the off-time.

Discipline

Your team is motivated, and they feel your trust - how are we going to make sure that your goodwill doesn't get abused? We need a way to make sure the things that need to finish on time - really get done on time.

First of all - keep an eye on the results - you must distinguish your perceived performance of the developer and his actual results. For example - a developer might have good presentation skills and sweet talk while underdelivering on the promises. His perceived performance might be adequate, but it might not represent their actual performance.

The solution is NOT Time tracking - which is only relevant during the first few months of a developer when you're getting to know each other. But better make your KPIs transparent and explicit. For example, if it's a Jira Task, define the acceptance criteria instead of a vague description. On the other hand, if it's a product owner - KPIs like the percentage of the closed sprint, team velocity should be in focus.

There's always something granular that you can measure, but don't overdo it because people tend to optimize themselves towards the KPIs. For example, developers would write lengthy code if you would have measured your developers by lines of code (which is weird, don't do that).

One of the ways I found to control my productivity from home is a method called timeboxing. I recommend it to everyone. Create timed entries in your calendar - blocks of 2-, 4-, or 6- hours where you only do the task. No emails, no meetings, no nothing. Just the task at hand - it keeps you focused, and you don't waste time.

Why not go remote

Remote work is not a silver bullet. Of course, it has its benefits - you don't have to commute, you spend less time talking about the weather with your coworkers. But then again - those aspects are also important. During the commute, you can listen to a podcast. During your work, you can recharge by talking about sports with your coworkers. It's all part of the experience, and remote work takes that away.

There is no Pair-Programming, no easy exchange of expertise between peers. Usually, you can have a quick chat about a new framework in the office - it's much more challenging when you're remote. However, a good alternative would be to have a channel where everyone can write everything - it's like a neverending stream of talking, office noise.
Employees miss that feeling of belonging. It's hard to replicate, but we can come to a similar atmosphere if we spend enough resources organizing face-to-face events.

In the end, I must say that times are changing, and giving your developers the possibility to work from home is not a perk now; it's a necessity. We're moving from paying people for the time they spend working for you to paying them for the value they bring you. Trust your team, set up a system that empowers them, and reap the fruits of their motivation.

Follow me on Twitter as I help early-stage startups. I post weird stuff, but may you'll like it. Also check out mindnow if you need some complex product development.

Running efficient meetings with engineers

Vadim Kravcenko — Fri, 24 May 2019 09:47:46 +0000

During my time as a software engineer, I always hated meetings, there's nothing more boring than going to a meeting for which it was not really necessary for me to be there, contributing nothing and just nodding along. That was a long time ago - now I view the meetings as a necessary evil and an efficient communication tool.

Over the years I've run lots of meetings - some of them successfully, some not so much, but I think I learned some lessons along the way. We at mindnow always have multiple projects running at the same time, so having meetings for us is important to keep the decision-making as seamless as possible. I would like to share with you some of my learnings on how to run efficient and productive meetings with your engineers. Take all of this with a grain of salt, as these are my personal observations and not necessarily best practices in the industry.

Simple Truth

Let's start with the simple truth - to finish any software project you will probably need to conduct at least a few meetings - with clients, with developers, with product owners, etc. The question now is: why would you want to meet with them? If you just want to tell them the status of the project - an email will be just fine. If you want to gather feedback a meeting may be a possibility.

In my opinion, there are only 2 scenarios when you really need a meeting:

you need something from someone, i.e. feedback, decisions, ideas, etc.
someone else needs something from you.

Can the meeting be an email instead?
If your goal does not fall into any of the categories above, then it's better to do an asynchronous communication via email.

Programmers prefer asynchronous communication so as not to be disturbed during their coding flow. This is completely understandable and needs to be taken into account when thinking about arranging a meeting. If there is no discussion necessary or if the discussion will be really short, it's probably better to write a long email rather than gathering everyone for 45 minutes.

Only relevant people in the meeting

People need to have a purpose
Having someone in a meeting should have a purpose. Communicate everyone's role in the meeting invitation to the person knows what is expected of him. I have a rule of thumb only to invite people who are part of the group that needs to make the decisions or have an influence on the decision. Everyone else will receive an email update after the meeting with the meeting protocol.

Have a moderator
This person should keep the meeting on point and redirect the flow of conversation back to the original topic if necessary. If any topics are raised that are not part of the agenda, they should be written down for future consideration. Some of those points may be discussed at a later date, this helps to ensure that some useful topics get discussed eventually and not get lost. It's not uncommon to uncover some topics that were hidden before and schedule a meeting to discuss it so as not to derail the current agenda and maintain the structure.

Have someone to take notes
Someone needs to be the note-taker during the meeting, it's either the same person all the time or a role that is being passed down in a circle. It's important to write down the decision and the action items that were agreed upon. After the meeting, everyone should get a copy of the document to read through later and refresh their memory.

Preparation and structure

1-1 meetings instead of group meetings
Do you really need to invite all of the people to the meeting? A 1-on-1 meeting is more productive as there's a dialogue happening and not just a few people talking while the rest are daydreaming. It builds a better relationship with your employees and also allows them to share ideas and concerns without feeling judged. Some people may rather introverted and not speak up during a meeting even when they have valuable input in mind.

Schedule all meetings on a single day
To avoid disturbing your developers too much it makes sense to schedule all meetings on the same day, that way they will know that Tuesday is the meeting day and will mentally prepare to discuss everything, instead of constantly being pulled out of the flow during other weekdays.

Do the preparations
The most frequent problem that I noticed afflicting meetings is vaguely defined objectives. If you're not exactly sure what you're trying to accomplish with the meeting, you can be sure no one else will know either. You need to do the preparations, set clear goals, clear structure, and presentation. Prepare these things ahead of time and specify exact timing for each block and moderate the flow.

The presentation/documents/other-relevant-material should be sent beforehand, no need to present it during the meeting. It makes sense to allow the people to review the documents before the meeting and think it over.

Staying on point

Summarize and repeat back what was discussed after each point
This goes hand in hand with the moderator duties. It's crucial that everyone is on the same page and no misunderstandings occur. To avoid this, each conclusion or a decision-item needs to be repeated and see if anyone raises any objections.

Have guidelines for your meetings
Having clear behavior guidelines is critical for healthy discussion. It's important to assume:

No one wants to purposefully make someone look bad. Assume the aim was positive and with good intentions.
We are all in the same boat, and everyone is equal during the meeting. You need to accept that there may be different opinions and opinions on different levels. The opinion of a junior developer will count as much as the senior developer’s. It's important to voice concerns even if it opposes the opinion of someone else. No need to automatically agree with a senior developer when he proposes a solution or says something, he may be wrong. We need to criticize and take a hard look at each solution - this allows us to find the best possible answer.
Ensure your ideas are clearly described so as to avoid any misunderstanding. It's the job of the speaker to make sure the ideas are correctly interpreted.
Be respectful and professional. No calling names or making it personal - we're all professionals, right?

Timing

Avoid pre and post lunch meetings
Hold meetings early in the morning, or later in the afternoon to make sure that there is nothing else distracting your team. Thinking about the lunch that you're going to eat and thinking about the lunch that you just ate is quite distracting.

Be punctual
If the meeting was scheduled for 08:00, then it starts at 08:00. Don't wait for latecomers. Soon enough the latecomers will start coming in at the exact time as no one likes to be embarrassed by barging in during the middle of a meeting.

Final thoughts

Here at mindnow, I try not to consume more than 10-20% of the developers’ time per week with meetings. There's literally nothing that can be discussed for more than 8 hours of meetings per week, and if there is, it can definitely be summarized into an email.

Share your thoughts on this? I'm interested in how you do meetings at your company!

Growing your interns into rockstars

Vadim Kravcenko — Fri, 10 May 2019 09:56:10 +0000

I consider this topic very important for everyone working in IT and even those that are currently interns, because eventually you will become Senior Developers and will need to nurture your own interns.

There are few things in the world of software development that have such a huge ROI as nurturing your interns to be the best possible engineers possible. While this goal is not achieved with every intern, I think it is the job of the manager (or the Team Lead) to bring out the best qualities in them and improve those qualities.

Over the years, I've had some interns that exceeded my expectation as well as those that didn’t due to being unmotivated. Usually the main difference between those two types was, that the former type had some sort of passion towards programming. And that's currently my rule of thumb - if I see that a person lights-up when he's talking about programming (e.g. some cool stuff he has built over the summer/weekend) - he's probably going to be a good developer in 2-3 years.

Nonetheless, every intern needs to be taught and nurtured. Here are some rules that I developed during my years that I'd like to share.

Pay them
This goes without saying, I never believed in unpaid internships. An intern is an asset with unlimited potential, so investing time and money into their future is a no-brainer.

Don't hire just anyone
Interns might not have much knowledge, but that doesn't mean they need to be hired differently than other employees. They still need to be tested for a cultural fit and for the adequacy. Furthermore, try to hire interns when you have projects for them to work on, there's nothing worse than an intern coming in and having nothing to work on.

Progressively complex tasks
This is the easiest thing to do, and also the most important one as I see it; the tasks that are given to an intern always need to be just a tiny bit harder than what he can currently manage. As a very basic example consider this: Your intern successfully wrote some script last week to do some aggregation, as a next task you might consider asking him to improve the solution with raw SQL, or add concurrency/parallelism, or implement it as CLI Tool. This keeps them on their feet as they browse StackOverflow trying to find a solution.

We all know how hard programming is at the start, so it's better to battle against many small challenges, increasing the difficulty over time, rather than only few big ones.

Stupid questions are acceptable. Once.
The policy that I try to enforce is that you can come up to me with any question, regardless of how dumb you think it might be, I will try to answer as thorough as I can or at least give some pointers. But this can happen only once per question, so if a week later a person comes up to me with the same question, I will tell him to try and find the answer himself.

Get the entire team involved in identifying and evaluating project risks. Everyone looks at the project differently, and sometimes the input from the student intern can be vital.

This has worked quite nicely over the years, because people started to really try and remember the answers and write them down if necessary. (Although usually the answers are in Slack, so it's even easier to go back and reread them)

Giving problems from different domains
It's important to let them have a taste of problems from different domains. This serves two purposes, the first one being - broadening their problem-solving spectrum. This is useful because it's possible that in the future they will end up in a situation where they will need to have some basic knowledge of some random domain. The more domains the person has "tasted" as an intern the easier it will be for them to adapt later.

The second reason being - they may end up liking that domain even more than they do their current one. This is self-explanatory, as the intern doesn't have many experiences, he may suddenly find a passion for something different.

A well-rounded experience is the most important asset for the interns future career.

As an example, consider this scenario: An intern working in the Frontend that has zero knowledge about the Backend - it's probably wise to let them fix some bugs in the Backend, even though it would take them more time. Or maybe give them some tasks from the DevOps for them to understand how the whole CI/Deployment looks like etc.

Teaching them standards
It's important to teach good standards from the start. Good standards result in good habits and good habits eventually lead to good quality code. The earlier a person develops some of those habits the better.

Good habits formed at youth make all the difference

It's far harder to try and get rid of bad habits than it is to develop good ones, so enforce standards as much as possible, even when the intern complains and doesn't really understand why they are so important. It will definitely benefit them. As an example of some of these good habits: Terminal usage as much as possible, reading documentation/comments before trying to use a library, rebase instead of merge, DRY and KISS principles, limiting function size, tests etc.

Working on their Soft Skills
In my opinion having good communication skills is as important as having technical skills. Some interns may think that their academic achievements are the most crucial part of their work success, but that's not the case. You will probably need to teach them the opposite. The idea of being a loner and coding in your cubicle for hours on end without interacting with anyone doesn't work nowadays.
This means you need to start teaching them good communication - translating ideas into words and conveying complex information in an understandable way. This is important not only inside your team but with other departments also.

Giving them freedom and holding them accountable
Although some interns truly need to be managed constantly (e.g. micro-managing), most people are able to complete simple tasks on their own and take responsibility for them.

He that is good for making excuses is seldom good for anything else.

Not even interns enjoy when someone is constantly looking over their shoulder. Let them work autonomously, but have an agreement that if the intern is stuck for more than several hours on a single problem he should come to you or ask for help from someone else.

Allow them to fail
You need to take into account that most likely, they will fail and make mistakes a lot.
Several years back I read a story about an intern who dropped a production database (sadly I don't have a link, if you do please send an email and I will add it, UPDATE: https://reddit.com/r/cscareerquestions/comments/6ez8ag/accidentally_destroyed_production_database_on/), and the supervisor got really mad about the whole situation and the intern was fired. I do understand the position of the manager, it's a pretty tough situation to be in, but the responsibility is 100% on the supervisor and not on the intern.
There should never be a possibility for the intern to fail so spectacularly, they need to work in a controlled environment.

Experience is the name every programmer gives to their mistakes.

Pair programming
This topic is always up for debate and people will have their preferences, but I think this can be a really productive thing. Allow the intern to be the driver, while you observe their thought process and guide it. Over time this will help them see the patterns on their own. Another bonus of this exercise is that the intern can't get distracted by Whatsapp or reddit while you're sitting there with them, so they are more concentrated.

Tech Talks, Books, etc
There's so many good tech talks on youtube, it's important to share them with your interns. Otherwise you're losing on an extra source of knowledge for them. I would suggest having a list of must-views and must-reads for the programming-language of your team’s choice. You can then have some Fun-Fridays where you watch those Tech Talks together or maybe some of your Senior engineers can hold their own internal tech talks (depending on the size of your company and the resources available)

Teach other people to manage interns
As crazy as it sounds, not everyone is aware how to mentor interns. A Guide with links to resources where one can learn how be a good mentor is a nice to have.

Regular 1 on 1 Meetings
You need to catch the blockers early, so a bi-weekly meeting with an intern about their progress is necessary. The usual questions include:

What did you do since our last meeting?
Did you have any problems during that time?
What do you need to improve your stay at the company?
What were the highlights/low points of your week?

Constantly improve your internship program
After the intern finishes his internship it's important to ask the critical questions:

What would you like to have known before the internship started?
Did you accomplish what you wanted to with this internship?
What was the most beneficial experience for you?
What would you have done differently?

In conclusion I want to say, that the first internship a person has, has a huge impact on their later life. It's important to make it a good one, let them have fun, let them explore, let them find their passion and don't make them stress too much as otherwise, they may reconsider their career choice and we really don't have enough developers in the world to allow that to happen.

Do you remember your first internship?