Connect with us


All you need to know about CRM — and the common pitfalls to avoid



Did you know we have an online conference about digital marketing coming up? Re:Brand will share strategies on how brands can still succeed in these unprecedented times.  

Let’s say you are working for a startup that sells robots across all industries. You take in orders from a variety of clients, and an operations team evaluates the orders and works with third-party providers to get your clients just the right robot.

Building the MVP was stressful but also a lot of fun. Your investors are excited and shower you with money. The next phase starts. You need more visibility on profitability and you want to acquire bigger clients that need more sophisticated invoicing. At the same time, you have a pretty sophisticated product roadmap to enable sales of higher-margin robots. Resources are scarce, but you still need to make sure to keep the company running.

As often preached for smaller companies, focusing on the things you are good at is a great rule of thumb. But what about all the areas that keep your company’s everyday operations running? You certainly don’t want to build a Customer Relationship Management (CRM) system or an accounting system. After all, there are lots of products out there that solve all the issues. But how will these systems work together with your existing order system?

This is where third-party integration comes in handy. So, let’s dive in and see if we can avoid some common pitfalls.

CRM integration

Whether you are doing low-touch sales (content marketing, social media ads, or newsletters) or high-touch sales (cold calling, attending conferences, or following up with existing clients via phone), a CRM system can give you a lot of visibility about how you are doing with existing clients and how successful you are with convincing new clients.

Oftentimes, the selection of a CRM system is mostly left to the sales and marketing department. In general, there is nothing wrong with that. After all, these people know best how to increase revenue and need the best support available. But even the best software is worth nothing if it doesn’t properly work together with your robot ordering system.

Include your tech department in the decision

Whether it’s the CTO or a dedicated engineer, keep them in the loop from the beginning. They are very likely to give you more insight on how the two systems will work together in the future.

And a word for the engineers: Keep an open mind toward third-party solutions. It’s easy to dismiss those because their API is not the best or their UI is ugly. However, it can be very rewarding to find elegant solutions around existing systems.

Nevertheless, there are a couple of topics that can be beneficial to talk about before making a decision. General topics like “Do we need this at all?” need to be addressed. But it is also a good idea to already have an idea of what the scope is. Is there a need for a two-way sync, or will the third-party system just follow the order system? Once the scope is out of the way, there also needs to be a technical discussion about implementation details such as webhooks or evaluation of the API limits.

Do you need a custom integration?

When it comes to integration, it’s not surprising that there are already existing platforms out there that promise to solve some of the problems you are likely to encounter. Currently, Zapier and IFTTT are the most promising ones.

Depending on the problem you are trying to solve, your robot order system might not even be involved in the integration. Say you are managing your newsletter subscribers with a CRM system such as Salesforce or HubSpot and just want a more convenient way to reach out to them via an email service provider such as Mailchimp, Zapier has tons of existing integrations to help you with that. From this point, choosing a provider that has a Zapier connector is a good way forward.

And even if it comes to integrating custom data (ordered robots and their price), Zapier Webhooks can act as a middleman for your integration.

On the other hand, if you are already sending data to a third party, why not send it directly to the CRM system? The more data you want to sync, the more useful a direct integration will be.

Which brings me to my next point.

Do you need two-way sync?

Usually, an integration starts out with a simple requirement such as Can we get all our clients into our CRM system?, typically combined with the values of individual robot orders, making it easier to utilize client segmentation tools.

However, sooner or later, it might be the case that people will want to make use of contact management tools that a CRM suite typically offers. These include features like deduplication, amending contact details with social media data, normalizing shipping addresses, or just simply deleting old contacts.

Changing contacts in a CRM system will most likely mean you will need to change contact details in another system, i.e., changes need to go both ways.

The implementation effort for this is way beyond a simple one-way sync, so this is an excellent point to think about how you want to use a new system strategically.

How will you be notified of changes from the CRM?

If you decide to have a two-way sync, there is a follow-up question: How do you know that something changed on the CRM side?

Most system providers have tools for this, but the best one for immediate changes is webhooks—essentially, an HTTP notification system that can be configured to let you know about relevant changes (for some systems, even on a field-by-field basis).

Guide to CRM Integration

If the system doesn’t offer webhooks, at least check if you can get a list of all entities that have recently been updated. This way, you don’t have to go through all contacts and deals only to update your own data. But please keep in mind that you will need to poll the system on a regular interval.

In this case, your order system would still change and create data via an API call on the CRM system. But all changes from the CRM system would be polled in a defined interval.

Guide to CRM Integration

What is worth noting is that the updates will be restricted to this interval and can lead to temporary data inconsistency. For example, when you only sync once a day from your CRM system to your order system, the data you are looking at in your order system can be up to 24 hours old.

Depending on what features the system offers, the integration task can vary in complexity and implementation time. Make sure to check what the system offers ahead of time and double check the plan you intend to buy. For example, some CRM systems offer webhooks in the higher-paid tiers.

An example here is HubSpot’s CRM, which offers webhooks in general but the webhook feature is only available in their Enterprise package. The accounting tools Zoho Books will offer five automated workflows (which include webhooks) in their lowest tier.

Is your data in good shape?

When it comes to creating data sets in an external system, it’s good to know what the data looks like in your own system. Luckily, there are not too many different ways of presenting contacts and deals, but one field that always causes trouble is the email field.

Different systems have different ideas of what a valid email address is, and here’s a spoiler alert—your clients might have provided you with invalid email addresses of all kinds. A lot of CRM systems will reject the creation of a contact with an invalid email address (and of course, the CRM provider defines what is valid and what isn’t).

Tip: If possible, only sync confirmed email addresses to your CRM. This will save you a lot of pain in the long run.

API limitations

Lastly, API limitations are something that needs to be addressed as early as possible.

Assuming there is an API (which is basically a must-have for any integration), it is beneficial to look at the limitations of the API. Most startups can cope with the basic API limits of most CRM systems. As an example, HubSpot offers 250,000 API calls per 24-hour period even in their free tier. On the other hand, it also limits calls to 10 per second (100 if you use OAuth). Market leader Salesforce only allows 100,000 every 24 hours but offers to purchase more.

Most of the time, you will easily fall within those limitations, but there is one thing to consider: What about your initial run? In the beginning, you will be pushing a lot of contacts and deals to your CRM (and possibly multiple times if there are problems). As a result, you might hit the daily API limit.

To mitigate this, you could test with a small data set and slowly increase the number throughout the implementation to remain within the API’s limit. For the initial migration, plan it out over multiple days or on a weekend. Alternatively, reach out to the provider and let them know your intentions. When you are in the evaluation phase (and haven’t paid for the system yet), they might be willing to increase your API allowance a little.

CRM implementation

Let’s say you are all in agreement. You picked a great CRM tool, and the engineers are confident that it can be integrated rather easily. You decided on scoping it to only push customer data and accepted robot orders. Therefore, two-way sync is not necessary, and address changes are only going to be handled in your own order system.

There are still a couple of best practices to follow during the implementation phase.

Try everything out on a test environment

In most cases, the CRM system will only be used after your integration is completed and ready to use. For this use case, it may seem appealing to just use the production system during development. After all, there is no production data you could be affecting. Once the development is done, you will simply remove all the test data you created, run an initial migration, and point your order system to this environment.

There are a couple of issues with this approach:

  1. You are just kicking the can down the road. Even if your go-live goes smoothly, sooner or later, there will be a feature request to change part of your integration. Given that the feature request is big enough, you will probably need another testing phase. At this point, a separate testing system is unavoidable; otherwise, you might end up messing up production data. So why wait with the setup until you are asked to implement the first feature?
  2. You end up with a messy configuration. It’s very likely that your CRM system needs some kind of configuration to suit the needs of your order system. Status names might need to be adjusted, custom fields usually need to be created, and so on. As most developers will need to get used to the CRM system, a configuration will be added that is not needed in the long term. In reality, this unused configuration is not removed later and might even stay in your CRM forever. By forcing the additional step of replicating the configuration from the test system to the production, you will most likely end up with a slimmer configuration on your production system.It should be noted that this can also play to your disadvantage if you forget to copy over configuration from your test to your production system, and you will end up with production errors.While there are some CRM systems that will help you compare and copy configuration items, in general, it will be useful to write down your configurations to not forget crucial items. Most CRMs provide an API to their configuration so it is possible to automate this step.
  3. You run a higher risk of polluting production data. Imagine for a second two developers working on an integration. You already have a staging system of the robot order system. This staging is connected to your CRM as well. Once your integration is shipped, you will need to remember to disconnect all three systems, or else, you might end up creating test data on your (now) production CRM.

All of these issues can be avoided by developing against a test system from the beginning. The production is only introduced at the very end, right before everything goes live. This way, you end up with a clean configuration, don’t run the risk of forgetting to disconnect local systems, and have a heads-up when implementing new features.

Define ID for matching up entities

Now, let’s start writing the actual integration code. Let’s take the example of syncing contacts to a CRM system. Presumably, you will need to create new contacts and update existing contacts. In order to distinguish a create from an update, you need to link the two entities. That way, you can check if the contact in your system exists on the external system.

While it seems appealing to just use the email address (after all, it’s a common identifier for a contact record), there is a more general solution—for every record, you sync to an external system hold and ID in your own database.

So, amend your contact table with a column called crm_id or external_id. This approach has a couple of advantages:

  • Because it is an ID, it will not change (unlike an email address or a phone number).
  • You can see if you need to create or update the entity without doing an API call first (if the external id field is empty, you can assume the contact doesn’t exist).



For example, let’s say you are a Ruby on Rails developer working on an application that needs to sync existing and new customers to HubSpot.

A simplified code example could look like this:

class HubspotSync
  def sync(customer)
    hubspot_return = if customer.hubspot_id.present?
      update(customer, customer.hubspot_id)

    customer.update(hubspot_id: hubspot_return['companyId'])


  def create(customer)
    response ="", map(company))


  def update(customer, hubspot_id)
    response = HTTParpty.put("{hubspot_id}", map(company))


  def handle_response(response)
    raise RuntimeError, "Unexpected Status code: #{response.code}" if response.code >= 500


  def map(company)
    # mapping code goes here
      properties: [
        name: 'name',

Notice how we are taking advantage of saving the companyId that is returned from HubSpot. Not only does it help us to determine if we want to update or create a company on HubSpot, but we can also see in the database table which entities are already synced to HubSpot and which are still missing.

When it comes to mapping fields, go freestyle

I have seen projects where implementation is preceded by creating a giant Excel spreadsheet defining which columns go where in the CRM system, with annotations of how data should be transformed.

In reality, there are just a few ways to represent contacts and deals. So instead of spending a lot of time thinking about how exactly you want to map, why not start with an experiment? Give the developer some space to figure out the mapping but also keep in touch so that questions can arise early.

At least for the general contact fields (name, email address, phone number, address), the mapping will be very simple, and transformations are usually trivial.

When it comes to status mapping for deals, a little bit more communication is helpful (sometimes, the first status is called open, sometimes new, and sometimes, the status model doesn’t match 100% so you’ll have to group statuses together). Instead of coming up with the perfect solution, look at your current data and see how it would best fit into the data model of the CRM. After all, you are an agile company, right?

In the example above, you can see a map method that converts our Rails model into a regular hash that is understood by HubSpot. For this particular use case, the only synced item is the name. For more advanced usage, you probably want to include more fields, but for a great outcome, start with an educated guess and communicate with the business side often for the details.

Consider retries

Let’s get down to the more technical level: implementing the actual sync between your system and the CRM. It’s almost a given that the integration will take place over an HTTP connection. Most systems provide an HTTP API, and all programming languages will let you make HTTP calls very easily.

Unfortunately, no matter how much money you spend on a CRM system, eventually, it won’t be reachable. This will happen at some point and there is nothing you can do about it. So, you might as well factor this in when you are developing your integration.

What this means in practice is—whenever you call an API, make sure your call is retried in case of a problem (500 status code from the other side). Implementing retries is something that is usually provided by third-party libraries of your language of choice.

Guide to CRM Integration

In addition to just retrying, you might want to consider logging what exactly happened. Getting a notification about an error that is already solved in the first retry can be frustrating.

So, instead of spamming your error channel with resolved issues, record all callouts with the number of retries to get a feel of how reliable the system is – a system that you just paid a lot of money for.

If we take the class that we created as an example and we stay in the context of Ruby on Rails, we can simply wrap the call in an ActiveJob and be fairly certain the call will succeed eventually. The handle_response method will raise an error in case of an unexpected status code, and ActiveJob will attempt a retry with an exponential backoff. For a more advanced solution, you should also consider 4xx status codes so that a retry is prevented and an error message is raised instead.

class HubspotSyncJob < ApplicationJob
  def perform(customer)

Make sure the system is actually used

OK, let’s assume you shipped it all. You are super proud of your work, and the system goes live. Now what? This is just the beginning. Because no matter how much testing you are doing, there will always be bugs and requested changes.

Problem is, you are not going to find out about these unless you actually use your system. And this happens for all kinds of reasons—the sales department is currently too busy to start using it, strategy changed, or even new systems are already being evaluated.

So, in order to avoid potential issues in the long term, make sure you have eliminated all obstacles that prevented production usage of the system. Communicate often between teams to get new requirements aligned. And if you find out that the system is just not going to work for you, turn off the integration. It sounds harsh and can feel very frustrating, but it’s less frustrating than always having to fix data inconsistency issues and deal with workarounds.

In the end, an integration project is a hell of a project, and there are a lot of things that can go wrong. It’s not very popular among engineers for a number of reasons, but it can be rewarding to see that an implementation has a positive impact on the productivity of people sitting next to you.

So for engineers—try to understand the needs of an external system such as a CRM or an invoicing system by asking concrete questions such as: How will this product make your life easier? Have you considered competitors? Why don’t they work?

For everyone else involved—get the engineers in as early as possible, trust them when they point out red lines, and don’t opt for a cheap plan when you can see that the implementation of the integration will make it a lot harder in the long run.

The Toptal Engineering Blog is a hub for in-depth development tutorials and new technology announcements created by professional software engineers in the Toptal network. You can read the original piece written by Leif Gensert here. Follow the Toptal Design Blog on Twitter and LinkedIn.

Published May 21, 2020 — 18:00 UTC


Hey snoozy Susan, here’s how to stop falling asleep at work




It’s 3pm on a Friday and you’ve had enough. Or maybe it’s just after 9am on a Monday and you’re struggling to get started, or even 12pm on a Tuesday and you’re falling asleep.

Sound familiar? If so, you’re probably used to the overwhelming struggle that is trying to stay awake at your desk when you really just want to fall asleep.

If it’s any consolation, you’re far from being alone. That’s why I’ve put together these few pointers to help you stay engaged, active, and awake while you’re at work.

[Read: The weirdo’s guide to WFH productivity: Sanity shower, squats, and snacks]

Get your steps in

Getting your morning routine right will undoubtedly set you up for a productive day and stop you from falling asleep.

Morning exercise is a good way of waking up your body and mind. If you can, go for a walk before you start work and get some fresh air.

You’ll feel more awake, and what’s even better, you’ll get your dreaded workout out of the way first thing.

Coffee isn’t the answer

Coffee is wonderful, it really is.

A good cup of the stuff can turn the worst of days into the best of days — but you shouldn’t abuse it.

If you’re going to be friends with caffeine, make sure you limit your intake because too much of it can leave you feeling lethargic.

I would recommend having one, or two (at most) cups of  in the morning and sticking to water for the rest of the day, which brings me on to my next point.

Stay hydrated

Water really is your best friend, especially when it comes to staying awake.

Dehydration can lead to fatigue because it impacts the flow of oxygen to the brain and can cause your heart to work harder to pump oxygen to all your organs, thus making you more tired and less alert.

Water can also help reduce stress. In fact, studies have show that dehydration can also lead to higher cortisol levels — the stress hormone — making it even harder to deal with daily problems.

You’ll need daylight

Natural daylight — or the lack of it — can have a huge impact on how you feel at work.

I used to work in a windowless office in a London co-working space and I’d find myself getting increasingly sleepy and restless throughout the day. I eventually realized this was mostly due to the lack of natural light — and it seems my conclusion wasn’t unfounded.

A study conducted by a US professor found that workers in day lit office environments reported an 84% drop in symptoms of eyestrain, headaches, and blurred vision symptoms all of which can detract from productivity and potentially lead to sleepiness.

Snack away

I don’t know about you but I used to experience an early afternoon drop in productivity and would start to fall asleep, particularly in the colder, drearier months — and then I started snacking.

It turns out this afternoon slump was probably caused by a drop in blood glucose levels and the good news is that I managed to solve this problem by keeping several healthy snacks within arm’s reach or just a short walk away.

Time yourself

Whether you’re working on an ongoing project or you want to tend to your overflowing inbox, own your productivity and hold yourself accountable by timing yourself.

Here’s a familiar scenario: You need to prepare a report by the end of the day but it’s 4PM and you’re struggling to stay awake. Stop what you’re doing, take a moment, breathe in, and set a timer on your phone. Give yourself a deadline and motivate yourself with the possibility of a nap once your work is submitted.

Get the hard stuff out of the way

Only you know when you feel more awake, so keep this at the forefront of your mind when you’re planning your day.

If you feel less sleepy in the morning, take care of the hardest, most boring tasks then and keep the fun stuff for later. If you’re more alert in the afternoon or evening, then save the most menial tasks until then.

There’s no hard science and if you’re fortunate enough to work somewhere that offers flexible working, you should use this to your advantage.

Let music be the food of love productivity

Lastly, but by no means least, I have to be honest with you: I can’t do anything without listening to music and while my taste may be questionable, that’s besides the point.

If you’re working from home or are lucky enough to have your own private office, why not sing along?

It’ll perk you up, you won’t fall asleep, and if you’re as bad a singer as I am, well, no one will hear you!

Published June 5, 2020 — 09:00 UTC

Continue Reading


A step-by-step guide to becoming a better engineering manager




The typical job description for many engineering manager roles is action-packed. It is a mix of hands-on coding, technical leadership and decision making, process and project management, product oversight, people management, finding and hiring talent… the list goes on.

In our work, we deal with both technical and people systems: we support individual engineers’ growth; help teams become successful; and make the organization more productive, functional, and innovative. Above all, an engineering manager is a service or support role across these various layers.

Perhaps most fascinating and difficult is the high-level of ambiguity that comes with engineering management. Many problems or questions don’t have straightforward answers. There aren’t absolute answers to what it means to be a good engineering manager either, but there are certain values and guideposts to follow.

In this post, I look at what can shape our thinking about our role as engineering managers and how to effectively support individual engineers, teams, and organizations.

What do engineers need to thrive at work?

It helps to start shaping engineering management roles by understanding what engineers need, and the environment in which they thrive. Research from performance coach and trainer Paloma Medina exposes six core needs humans have (including at work). She calls this research the BICEPS model:

  • Belonging. As humans, we strive to be part of a community of like-minded people where we understand and support each other. We also want to feel as if we are not being discriminated against or marginalized. Belonging is really important to me personally: I love working as part of a distributed team, but I also really enjoy seeing people in person every once in a while. It makes me feel more connected to them.
  • Improvement. We also seek to continuously learn, improve, and grow in areas that matter to us, as well as to our team or company.
  • Choice. We want to have choice, control, and autonomy over important parts of our lives. In one of my previous roles, I took on a lot of work to drive organizational change. But ultimately, the control I had over my domain was limited due to organizational issues – which led me to leave the company.
  • Equality. We want to know that our access to information, money, time, and other resources is fair and equal for everyone – not just for ourselves, but also for the people around us. Everyone’s needs should be treated as equally important.
  • Predictability. We look for certainty, safety, and stability in our lives. We also want goals, strategy, and direction to be consistent – and to not change too quickly. I’ve been leading teams in fast-growing startups for the last couple of years, and when there’s a lot of change happening, it’s a challenge to instill predictability in teams.
  • Significance. Deep down, all of us seek meaning, importance, and status. We also want to be appreciated for our work by people whose opinions mean something to us.

If our core needs are threatened, people resort to fight-or-flight modes of reaction, which are very stressful. The failure to meet core needs has high costs for organizations by harming people on our teams. So how can engineering managers put the BICEPS model into action to help their teams thrive?

Using trust-based relationships to help engineers grow

The foundation of being a good engineering manager is getting to know our teammates and understanding what is important to them. Here are a few places to start building trust within your team.

1. Ask questions

One of the most powerful tools managers have is asking good questions. The basis for doing our jobs well is listening, observing, taking note of what motivates our teammates, and really digging into their responses to our questions. I usually gather questions before I meet with my teammates one-on-one, so I am prepared and I can guide the conversation towards understanding them better.

Over time, I have built a kit of one-on-one questions that I pull out when I need some inspiration for these conversations. Asking questions helps us adjust our leadership style to the people we are leading. It also ensures that they feel understood and heard, which are really important pillars of inclusion and belonging.

2. Be curious

People are full of surprises, and sometimes our teammates’ reactions may be completely different from what we expected. I once received a message from an engineer on my team who was deeply upset about the specific wording used in a product-release note to customers.

At first I did not understand their strong reaction. But when we talked, I learned the engineer had been overruled by someone with more power, making them feel helpless, and threatening their core need for choice and equality.

What managers might perceive as no big deal can be enormous threats to other people. Cases where we’re surprised by our teammates’ reactions are good opportunities to focus on human-centric responses, like giving people the opportunity to talk through their feelings.

3. Connect to the bigger picture

Creating an impact is a very good motivator for all of us, so helping engineers understand how their work connects to the bigger picture (how it helps users or supports other teams) is an extremely important and strategic skill for managers.

While goal-setting frameworks like OKRs can help, it is also crucial to align engineering initiatives with higher-level goals, and connect them clearly with user value.

4. Involve engineers in decision making

Feeling that decisions are fair and equitable is an important component of the BICEPS model. When we make decisions, it is helpful to ask everyone for their opinions first, and take their opinions into account.

It is not always possible to go with what everyone wants. But we can still do a good job at contextualizing the decisions we make, and helping people understand that their feedback was considered.

5. Give feedback for growth

One of the best things we get to do as engineering managers is support engineers’ growth. Give feedback regularly to help the people on your team understand where they are at and grow – by course-correcting where needed, as well as by doing more in the areas in which they are already doing great. Managers need feedback as well: it’s important to regularly ask your team for feedback so you can make adjustments.

6. Coach engineers

Coaching helps people find answers themselves, improves their problem-solving and leadership skills, and increases learning, resilience, and self-management.

7. Sponsor engineers

Think back on your career, and whether you have had a mentor who connected you with someone, put your name forward, and used their influence to make a difference in your career. Be that person for someone else: invest in their growth, lift them up, and put your weight behind their success. Supporting your team’s success can make a real difference for them.

This is the foundation of our work as engineering managers.

Driving a culture of trust and continuous improvement on teams

The next important building block in our work as engineering managers is the team. According to research, high-performing teams need the following elements.

  • Psychological safety. This is about believing that we will not be rejected, and feeling free to express our work-related thoughts and feelings to the people around us. It also means believing that others won’t think less of us if we make a well-intentioned mistake or ask for help.
  • Structure and clarity. Everyone on the team should understand expectations, goals, and accountability.
  • Meaning and impact. High-performing teams find a sense of purpose in their work, and know that their work has an impact.

Luckily for managers, this research neatly aligns with the BICEPS model. All human core needs are represented and have impact at the team level as well. By understanding and responding to people’s motivations, leaders create the basis for teams to express themselves – and provide the structure, meaning, and impact they need.

1. Build trust

The first step in creating structure is building relationships. For our distributed teams at CircleCI, we’ve built different structures to help teammates do that, such as regular pair programming rotations and engineering talks.

2. Structure around how we collaborate

Our engineering department has doubled in size for three years in a row. Over this time, we’ve moved to a more streamlined engineering delivery process for all teams. But we still leave it to the teams to decide how to implement t day-to-day processes, including daily standup meetings, planning sessions, or collaboration. Every team has specific needs, and they know best how to address them.

3. Remove blockers

Structures can also help mitigate the impact of getting blocked at work. We all know how frustrating it is to be stuck. Putting up pathways to help people get unblocked can be really important – for example, setting up regular pair programming rotations, investing in self-serve information access, supporting each other across teams, putting up escalation paths for people to get help when they need it, or helping people support each other through knowledge-sharing.

4. Continuously improve

We can use retrospectives to discuss and improve how we work together. Blameless postmortems are also a great tool to help understand problems and drive towards solutions. Code reviews, mentoring, or knowledge sharing can help team members learn from each other.

The way we talk about learning matters – especially the way we discuss mistakes. These decisions will fundamentally shape the culture of our teams, and determine whether people feel safe or threatened in their core needs.

5. Drive toward alignment

Communicate strategy, direction, and relevant tactical details to your teams – and remember it’s almost impossible to over-communicate these details. Always repeat what’s important.

As engineering managers, we are like mortar: we connect structures, teams, and people. We hold them together, but also identify and fill gaps as needed. Handling ambiguity is one of the most important and difficult aspects of engineering management. For a lot of work in our field, there are no straightforward answers, let alone resolutions.

Our work isn’t so much about us; it’s about the people, teams, and organizations we support. We build structures to help others shine.

Supporting organizational change

Lastly, creating environments in which engineers can thrive is about supporting our organization. We need to use our power as managers to drive organizational change, no matter the size of our businesses.

1. Advocate for change

To be effective as managers, we need to push for organizational change to improve the larger structures around us. For example, we may need to advocate for more clarity around engineering manager roles, have conversations about what engineering management should be like in our company, and determine requirements for hiring engineering managers.

2. Manage up

Managing our own managers is a useful but difficult skill. Driving organizational change also means making sure that our engineers’ concerns are heard at the highest levels, and that we use our power to make sure engineers have a voice in the rest of the organization.

3. Build frameworks and standards

While it is always important to make room for individual needs, structures and frameworks for managers help us hold each other accountable. They also help level the playing field and build in equality for the people on our teams.

On my current team, every quarter we pick some high-priority projects to improve how we work as an organization. Most recently, we’ve worked on our hiring process and incident remediation; last year, we developed an internal career growth framework for engineers.

Growing as a leader

Being a good engineering manager isn’t always a straightforward path; a lot depends on where we are at in our careers and where we are looking to go, as well as the growth stage, size, and needs of our organizations. In our daily work, we hold vast amounts of uncertainty while also trying to make progress.

An overarching theme in my work in engineering management has been growth and improvement. We rarely deal with greenfield projects or are able to build a team or department from scratch. Even when we do, we build on existing structures in our organization. I believe our supporting role largely means helping engineers grow, supporting teams at continuously learning, and helping organizations become better.

As engineering managers, we frequently face questions that don’t clear right or wrong answers. Many years ago, my leadership coach encouraged me to use those kinds of uncertain situations to ask myself, “What kind of leader do I want to be?”

I want to leave the last call to growth and improvement with you (and me): no matter what your role or company is like, work on shaping your approach to engineering management. Get to know the people that you work with, and use feedback to help them course-correct. Build teams that are psychologically safe places, where people find meaning in a shared purpose. 

And use your power and privilege to drive change in your organization. Make people the center and focus of your work, and build on that foundation to create an environment in which they can thrive. Always push to continuously improve. Lead with humbleness, empathy, and lots of curiosity.

Published June 5, 2020 — 06:30 UTC

Continue Reading


Why entrepreneurs need to find their ‘inner clown’




Boris is the wise ol’ CEO of TNW who writes a weekly column on everything about being an entrepreneur in tech — from managing stress to embracing awkwardness. You can get his musings straight to your inbox by signing up for his newsletter!

Contrary to what many people may think, learning how to be a clown is not part of a circus school curriculum. I know, because I dropped out of school when I was 15, signed up for circus school, and graduated as a professional juggler three years later. 

Circus school was very much about specializing in one skill, spending countless hours practicing, and building an act around that. Becoming a clown, however, followed a completely different process.

Clowns, all joking aside, take being a clown very seriously. The thing is, you can’t just train eight hours a day for it and then eventually succeed, like with juggling. A real clown IS a clown. He or she isn’t acting. The clown is already there, hidden inside of us, and the course focused on finding your inner clown and peeling away the layers of respectability, rather than trying to make you simply act like one. 

Be authentic

Many years ago I knew a young entrepreneur who was always hustling. When he found an opportunity to make money, he went for it. He had no specific interest or hobby and was just interested in doing business. He’d buy and sell and make a margin and that was enough for him. I recently bumped into him and he’s now rich and successful and still hustling buying and selling ever more expensive things. 

[Read: Working from home is great — until your co-workers show up]

While this is clearly a success — he’s happy and rich and he has achieved his goals and dreams — I personally find it hard to be positive about what he achieved. I can’t relate because my starting point was always my interest in technology and innovation, building upon who I was at my core. Only caring about wealth is a very specific kind of poverty. 

I do realize that’s a very privileged thing to say, but if you can, try to unpeel your traditionalist layers and find out who you really are. Nothing can beat authenticity.

I heard a comedian describe once how he developed his act. At first, he began looking for jokes in the world around him, but soon he realized the best jokes were to be found within. 

When he felt uncomfortable about something, he discovered it paid off to poke and prod at it and build the joke around the discomfort it caused him. The deeper he went, the more personal and funnier his routine became, and also more distinctive. 

I guess we all have our inner clown to discover. And my inner clown is a very specific one. I couldn’t play a different clown and care about the things I don’t care about. Now let me ask you, who’s your inner clown?

Can’t get enough of Boris? Check out his older stories here, and sign up for TNW’s newsletters here.

Calling all techies

Sponsored content

You’re invited! Join AWS and DevOps Institute to learn how continuous improvement can simplify your organization’s delivery toolchain and transform the way it brings software products to market.

As more and more organizations embrace a DevOps approach to software development, engineers are expected to design, build, and patch products faster than ever. Join AWS and DevOps Institute to discover how to simplify your delivery toolchain and create more meaningful next-level software experiences for your customers. We’ll explore the benefits that a continuous improvement mindset can bring to your organization and discover helpful software solutions in AWS Marketplace.

WHEN: JUNE 16, 2020, 11:00 AM PT (2:00 PM ET)

Published June 4, 2020 — 15:00 UTC

Continue Reading


Spanish English