It is the mission of Black Tangent to help medium and large organizations make data driven decisions through digitalization and automation. Our methods empowers the users by applying the knowledge that exists within the organization to open up possibilities to cut costs, support sustainable innovation and create new opportunities.
New projects come about when the client fills out our contact form or by sending a email directly to enquiries inbox.
We have a Zapier hook, which adds the enquiry as a task inside our Pitches project inside Asana. Pitches are sorted according to their current status: iceboxed, paused, qualifying, negotiating. The whole team is added as a follower to the ongoing pitch, so they’re kept informed.
In order to progress, enough members of the team must express interest in the project for us to think we could assemble a team to work on it. If there’s no team interest, we’ll apologetically decline the lead. Where appropriate, we’ll offer a suggestion for where they might look next.
The developers involved will report back to the team and inform with a summary of the discussion.
They should also make a preliminary recommendation to either accept or reject the lead.
We respect confidential information at all times and won't disclose anything to our other clients.
We price and bill projects on a flat weekly rate according to the number of developers who will be required.
When we're able to gain consesnus for the project and assemble a time we'll send over and Engagement summary which sets out:
We are a Singapore incorporation so all rates are in SGD and will have VAT added on. Invoices are automatically sent out weekly, every Wednesday, with net-14 payments terms.
International clients can pay via direct bank transfer.
The process will start after the contract has been signed and the client has payed for the first sprint.
We use Scrum as our main agile methodology. We believe that to operate as a modern and efficient consultancy today you have to embrace change and constantly focus on improving products.
The workday for a developer is 8 working hours—while in rare situations it may be a little longer, this is the goal we hold ourselves to. If any developer is consistently working longer than this, that indicates that there’s a problem to be resolved.
As a team, we are highly productive and invest heavily in tools to allow us to be this way. Our philosophy is always that the number of hours worked has no correlation with the quality of work produced.
When working on a project sprint, the amount of time that will be spent on client work will be up to 7 hours (lunch break not included) in a day. The remaining hour in the day goes towards off-sprint work such as internal reviews, research, planning and internal work, all of which allows us to deliver better results when we’re on a sprint.
We work on client sprints from Monday to Friday. Since the team and clients are entirely remote, we don’t stop client work on public holidays. Although it’s rare for us to work over Christmas and New Year.
Full-time developer make their own decisions about how much holiday they’d like to take. We try to make sure that everyone takes 30 days a year.
Team members announce their holiday plans on Slack to check for scheduling issues. If there are no major problems, they then add their holiday dates into our shared Google Calendar marked with Yellow.
To minimize holiday disruptions, we ask that developer try and plan holidays to avoid departing mid sprint. Since sprints run Wednesday to Tuesday, this means that departing on Wednesdays, and returning on Tuesdays is easiest for everyone.
Working remotely is one of the best-known elements of our culture. It has been the way we’ve worked since the very beginning, and we intend to stick to it. For us, it’s a way to allow our team the flexibility to build great lives around their work, which in turn, helps them to enjoy their jobs more and to be more productive.
We are very flexible about where team members choose to live and work. The biggest requirement is that regardless of where you choose to be based, you must make sure you have an internet connection that’s good enough to handle video calls with clients and the rest of the team.
Team members get login details for our OpenVPN servers. VPN usage is compulsory whenever you’re working on public wifi.
Where we feel it would help us to do a better job on a project, we may bring in collaborators to help us. These contractors will be booked on the same, weekly basis, and will become full-time members of the project during the booking.
Confidentiality of project and client information is important, so each of these contractors will sign a standard Independent Contractor Agreement. This will be sent out from HelloSign, and sets out our standard confidentiality terms, along with other conditions for working on the project.
We’ll also send a single booking document, which will set out the dates we’re booking to work together during.
Collaborators will be added to the project management tools (such as Pivotal Tracker) that they need in order to carry out their roles.
We use Slack for internal chatter, including marketing discussion, and general chat between developers.
For all internal communication that requires a task to be completed use Pivotal Tracker.
As for the tools we use for each project—that really depends on the project. We’ll often use Pivotal Tracker to run projects, but if the client has a defined workflow and we need to integrate into it, we’ll switch from anything from GitHub issues, to apps such as JIRA.
Internal calls usually happen over Slack — we feel the audio quality is better than Google Hangouts or Skype. There are always video calls.
Since some of our developers are located in the same cities we meet up for social food and drinks. This usually happens on the last Thursday of every month. Before each meetup we all join in on a Hangout talk about how the month went and potential topics for the evening.
While we understand the need of everyone in the team to be able to hit deep focus, we also believe that teams build better products together than any one person can by themselves. To accomplish this, we make sure that regular team calls are a built in part of every workday.
We use Screenhero lots for internal pairing sessions, and also frequently pair on Google Docs.
Each month, during the first week of the month, every developer has a 1:1 call (or an in-person chat, if they’re in the same city) with Ole. In short, it’s a chance to have a chat about how the month went, and what else our company can be doing to help you grow, and make life better for you.
One of our most important cultural values is that we will never settle. This means we work really hard to help our developers grow.
We believe in using this to set individual goals or long term goals which eventually will broaden our knowledge base and increase the team's strength. These goals should be fairly ambitious, if you're over or under your goal by the time of evaluation we 'll use this again to set the next goal or pivot. OKRs are not synonymous with employee evaluations.
OKRs are registered in Pivotal Tracker with a description of your goal and a due date.
Also described in this article Set goals with OKRs
We hold fast to the philosophy that great results on complex challenges come from building a great team around the problem. We don’t believe that any of our developer should be working solo.
So we build small, cross-functional teams for each project. This means that depending on the project needs, we’ll typically have 2 developers working on each client sprint.
We also don’t feel that great work comes when our attention is split between multiple projects. A consistent project team, which doesn’t change on a regular basis, is the best way to build great relationships with our clients and to make sure that team is productive and understands the project deeply. So team members will stay on the same project for the whole sprint, working full workweeks on that project, rather than working on multiple projects at once.
Team schedules are shown in Google Calendar, and teams are responsible for managing their own schedules and also requesting help from other team members, as needed. Where possible, we will aim to avoid having sprints run back-to-back. Downtime in between sprints is for internal work, including marketing, blogging, and building team tools.
To make sure we start the project in full speed we'll send over some research we've done and some tasks prepped for the client.
Getting solid answers on these points will have a huge impact on the quality of work during the first week. Understanding the client's vision and direction absolutely necessary for the project to go forward in a fast pace.
During the first day we start out by using the information received by the client up front. We'll spend a few hours looking at the information at hand and understanding the client's vision. We'll contact the client directly if we find any issue with the provided information or we feel something is missing.
We work together to set out priorities for the sprint and break down weekly milestones.
We use Pivotal Tracker for collaboration with the client. This allows us to get a good grip of the amount of work and prioritize the tasks accordingly.
We see the importance of rapid-prototyping and transparency. Our first goal is for the client to see the result of development fairly quickly and that the work is transparent. The client should be able to follow up on ongoing work so there will be no major changes, surprises or regressions in the development.
Before we start the project we decide on the technology best suited for the project.
At the end of the development we'll end up with a repository containing: